www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.011 release

reply Walter Bright <newshound1 digitalmars.com> writes:
Bug fixes, some enhancements.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.1.011.zip
Apr 11 2007
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:
 Bug fixes, some enhancements.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.011.zip

From the changelog: * final for variables now works. What does this do? I didn't see anything in an obvious place in the spec explaining it. Also, I have updated the keyword index: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Apr 11 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kirk McDonald wrote:
  From the changelog:
 
 * final for variables now works.
 
 What does this do? I didn't see anything in an obvious place in the spec 
 explaining it.

It's the first part of the final/const/invariant thing. No documentation is written on it yet. All final is is that if you declare a variable as final, you can only initialize it. It cannot be reassigned.
 Also, I have updated the keyword index:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification/KeywordIndex

Thank-you.
Apr 11 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:
 Kirk McDonald wrote:
  From the changelog:

 * final for variables now works.

 What does this do? I didn't see anything in an obvious place in the 
 spec explaining it.

It's the first part of the final/const/invariant thing. No documentation is written on it yet. All final is is that if you declare a variable as final, you can only initialize it. It cannot be reassigned.

Is that like what "const" does, at the moment? L.
Apr 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Lionello Lunesu wrote:
 Walter Bright wrote:
 All final is is that if you 
 declare a variable as final, you can only initialize it. It cannot be 
 reassigned.

Is that like what "const" does, at the moment?

Yes, except it only affects the symbol.
Apr 11 2007
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote

 some enhancements.

I believe that "macro" is the wrong wording for the intended semantics of manipulating ASTs. D supporters might get into serious argumentative troubles when negating the usefullness of C macros on one side and OTOH have to hail AST manipulators which irritatingly have the same name: "macro". Please choose "ast" or any other word that does not remind of mere textual exchanges. -manfred
Apr 11 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:eviatg$7r5$1 digitalmars.com...
 Walter Bright wrote

 some enhancements.

I believe that "macro" is the wrong wording for the intended semantics of manipulating ASTs. D supporters might get into serious argumentative troubles when negating the usefullness of C macros on one side and OTOH have to hail AST manipulators which irritatingly have the same name: "macro".

..but then you have Lisp programmers who will feel right at home calling it 'macro,' which is, I guess, the motivation for calling them as such. I don't think it'll be much of a problem; the D macros will probably be able to take the place of most C preprocessor macros, so it'll just be "D's macros are better than C's."
Apr 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 "Manfred Nowak" <svv1999 hotmail.com> wrote in message 
 news:eviatg$7r5$1 digitalmars.com...
 Walter Bright wrote

 some enhancements.

of manipulating ASTs. D supporters might get into serious argumentative troubles when negating the usefullness of C macros on one side and OTOH have to hail AST manipulators which irritatingly have the same name: "macro".

..but then you have Lisp programmers who will feel right at home calling it 'macro,' which is, I guess, the motivation for calling them as such.

Yes, that is the motivation, and my impression from talking with people about it is it won't be a problem. I intend to refer to them as "AST macros", rather than C's "text macros".
Apr 11 2007
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 Bug fixes, some enhancements.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.011.zip

Hmm .. nice ref is better than inout .. um, What is the macro keyword for? Where is it documented? If at all? gj, as always
Apr 11 2007
next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Hasan Aljudy wrote:
 
 
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

Hmm .. nice ref is better than inout .. um, What is the macro keyword for? Where is it documented? If at all? gj, as always

Quoth the log: * Added keywords ref and macro. * ref now works as a replacement for inout. I think this means what it means - Walter just reserved the keywords, and 'ref' is now a synonym for 'inout'. -- - EricAnderton at yahoo
Apr 11 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Hasan Aljudy wrote:
 What is the macro keyword for?

For the future (unimplemented) AST macro feature.
Apr 11 2007
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 Hasan Aljudy wrote:
 What is the macro keyword for?

For the future (unimplemented) AST macro feature.

Aha! Sounds interesting .. I haven't been following the discussions lately, was this discussed somewhere? I'd like to see .. like; what kind of ideas are laid out on the table? Do you have something specific in mind?
Apr 11 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Hasan Aljudy wrote:
 Walter Bright wrote:
 For the future (unimplemented) AST macro feature.

Aha! Sounds interesting .. I haven't been following the discussions lately, was this discussed somewhere? I'd like to see .. like; what kind of ideas are laid out on the table? Do you have something specific in mind?

I think there was a thread entitled "AST macros" a month ago.
Apr 11 2007
parent reply jcc7 <technocrat7 gmail.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Hasan Aljudy wrote:
 Walter Bright wrote:
 For the future (unimplemented) AST macro feature.

Aha! Sounds interesting .. I haven't been following the discussions lately, was this discussed somewhere? I'd like to see .. like; what kind of ideas are laid out on the table? Do you have something specific in mind?


Here are links to some of the posts in the "AST macros" thread: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50484 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50595 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50619 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50684 Or if people prefer to view the archives: http://www.digitalmars.com/d/archives/digitalmars/D/AST_macros_50484.html (Random note: By the way, the web interface's threading doesn't seem to work as well here as it does with some other threads. I wonder why that is. Anyway, it's still better than nothing.) jcc7
Apr 11 2007
parent Charlie <charlie.fats gmail.com> writes:
jcc7 wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Hasan Aljudy wrote:
 Walter Bright wrote:
 For the future (unimplemented) AST macro feature.

I haven't been following the discussions lately, was this discussed somewhere? I'd like to see .. like; what kind of ideas are laid out on the table? Do you have something specific in mind?


Here are links to some of the posts in the "AST macros" thread: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50484 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50595 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50619 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=50684 Or if people prefer to view the archives: http://www.digitalmars.com/d/archives/digitalmars/D/AST_macros_50484.html (Random note: By the way, the web interface's threading doesn't seem to work as well here as it does with some other threads. I wonder why that is. Anyway, it's still better than nothing.) jcc7

I've said it once Ill say it again, Justin you are researching master :). Charlie
Apr 11 2007
prev sibling next sibling parent Tom <tom nospam.com> writes:
Thanks! (I'll keep repeating it)

Walter Bright escribió:
 Bug fixes, some enhancements.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.011.zip

Apr 11 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Bug fixes, some enhancements.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.011.zip

Great. I updated the D mode for Emacs [1] with the new keywords. I also noticed that I had forgotten to include 'inout' and 'cast' as keywords previously. [1] http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport/EmacsDMode --bb
Apr 11 2007
parent reply Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

Great. I updated the D mode for Emacs [1] with the new keywords.

I've done the same for the UltraEdit syntax file here: http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport/UltraEdit Sean
Apr 11 2007
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

Great. I updated the D mode for Emacs [1] with the new keywords.

I've done the same for the UltraEdit syntax file here: http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport/UltraEdit

Also Kate/KDevelop users will get an update in the next few days with the automatic update tool in Kate. Those who are in hurry can fetch it manually from http://bugs.kde.org/show_bug.cgi?id=144087.
Apr 11 2007
prev sibling next sibling parent Max Samukha <samukha voliacable.com> writes:
On Wed, 11 Apr 2007 01:40:39 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Bug fixes, some enhancements.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.1.011.zip

Great! What are the chances that recursive instantiations of template mixins would be allowed?
Apr 11 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:
 Bug fixes, some enhancements.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.011.zip

---- struct HttpStatus { int code; char[] name; } struct HttpResponses { final HttpStatus Continue = {100, "Continue"}; } void foo (inout HttpStatus status) { } void main () { foo (HttpResponses.Continue); } --- "Error: cannot modify final variable 'Continue'" The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference? (if you change 'final' to 'const' within the HttpResponses struct, the same error is generated, and saying "final" rather than "const")
Apr 11 2007
next sibling parent reply kris <foo bar.com> writes:
kris wrote:
 Walter Bright wrote:
 
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

---- struct HttpStatus { int code; char[] name; } struct HttpResponses { final HttpStatus Continue = {100, "Continue"}; } void foo (inout HttpStatus status) { } void main () { foo (HttpResponses.Continue); } --- "Error: cannot modify final variable 'Continue'" The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference? (if you change 'final' to 'const' within the HttpResponses struct, the same error is generated, and saying "final" rather than "const")

In a similar fashion, this kinda' thing used to work just fine: --- struct Foo { final char[] x; } static Foo foo = {"something"}; --- "Error: too many initializers" How is one now supposed to declare struct contents that are immutable after being set to an initial value?
Apr 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
kris wrote:
 In a similar fashion, this kinda' thing used to work just fine:
 
 ---
 struct Foo
 {
     final char[] x;
 }
 
 static Foo foo = {"something"};
 ---
 
 "Error: too many initializers"
 
 How is one now supposed to declare struct contents that are immutable 
 after being set to an initial value?

That looks like a compiler bug.
Apr 11 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
kris wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

---- struct HttpStatus { int code; char[] name; } struct HttpResponses { final HttpStatus Continue = {100, "Continue"}; } void foo (inout HttpStatus status) { } void main () { foo (HttpResponses.Continue); } --- "Error: cannot modify final variable 'Continue'" The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference?

In the future, inout would be replaced with "const ref".
 (if you change 'final' to 'const' within the HttpResponses struct, the 
 same error is generated, and saying "final" rather than "const")
 

Apr 11 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 kris wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

---- struct HttpStatus { int code; char[] name; } struct HttpResponses { final HttpStatus Continue = {100, "Continue"}; } void foo (inout HttpStatus status) { } void main () { foo (HttpResponses.Continue); } --- "Error: cannot modify final variable 'Continue'" The above used to compile. How is one supposed to declare and populate a struct that cannot subsequently be changed, and can also be passed by reference?

In the future, inout would be replaced with "const ref".

Hm... so what should be done to get this working until the new 'const' semantics are in place? Sean
Apr 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Hm... so what should be done to get this working until the new 'const' 
 semantics are in place?

Drop the final for the moment. Passing a final variable as inout should never have worked, anyway, because the function can change the final value.
Apr 11 2007
prev sibling next sibling parent Serg Kovrov <kovrov no.spam> writes:
Walter Bright wrote:
 In the future, inout would be replaced with "const ref".

To me it's 'in' seems more like constant reference, but 'inout' like just reference. Anyway, why to replace in/out/inout? Just change 'in' to be "const ref". -- serg.
Apr 11 2007
prev sibling parent Charlie <charlie.fats gmail.com> writes:
 In the future, inout would be replaced with "const ref".

Oh no, have you finally given in to C++ style 'const' , say it aint so!
Apr 11 2007
prev sibling parent reply freeagle <dalibor.free gmail.com> writes:
Walter Bright wrote:
 Bug fixes, some enhancements.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.011.zip

what was wrong with "inout" ?
Apr 11 2007
next sibling parent reply Serg Kovrov <kovrov no.spam> writes:
freeagle wrote:
 what was wrong with "inout" ?

Nothing. I hope 'inout' will stay "read-write reference" (&), and 'ref' will become "read-only reference" (const &). Although 'in' seems better name for it... But well, we'll see. -- serg.
Apr 11 2007
next sibling parent freeagle <dalibor.free gmail.com> writes:
Serg Kovrov wrote:
 freeagle wrote:
 what was wrong with "inout" ?

Nothing. I hope 'inout' will stay "read-write reference" (&), and 'ref' will become "read-only reference" (const &). Although 'in' seems better name for it... But well, we'll see.

anything else. Even newcomer will guess what they mean, ref looks more cryptic
Apr 11 2007
prev sibling parent Charlie <charlie.fats gmail.com> writes:
Serg Kovrov wrote:
 freeagle wrote:
 what was wrong with "inout" ?

Nothing. I hope 'inout' will stay "read-write reference" (&), and 'ref' will become "read-only reference" (const &). Although 'in' seems better name for it... But well, we'll see.

I second this , having one word to mean 'constant reference' would be far preferable to a 'const' qualifier, and leave inout to mean what its always meant. Charlie
Apr 11 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
freeagle wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

what was wrong with "inout" ?

Got me. in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent. I can't say I understand the reason for a new keyword here. Sean
Apr 11 2007
next sibling parent reply Marcin Kuszczak <aarti interia.pl> writes:
Sean Kelly wrote:

 freeagle wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

what was wrong with "inout" ?

Got me. in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent. I can't say I understand the reason for a new keyword here. Sean

What's more it is common notation in UML tools - there is no 'ref' but there is in/out/inout. So why to change? -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Apr 11 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Marcin Kuszczak wrote:
 Sean Kelly wrote:
 
 freeagle wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip


and CORBA, IIRC), and the names seem internally consistent. I can't say I understand the reason for a new keyword here. Sean

What's more it is common notation in UML tools - there is no 'ref' but there is in/out/inout. So why to change?

I think the notion of using 'ref' was to avoid a "misrepresentation of intent" when coding libraries. In other words, using for example "void foo (inout SomeStruct)" when the referance to the structure is used solely to avoid copying, and not because the function intends to modify it at all. To some people, this is apparently incongruent. Personally, I'm fine with it, as my autognostic interpretation of 'in', 'out', and 'inout' is as a description of how data flows. It either flows 'in'to the function, 'out' of it, or 'in-' and '-out' freely. *shrug* I'd be plenty cool with having /both/ 'ref' and 'inout' for that purpose, then, except that it feels just a little wrong to have two keywords with identical semantics. -- Chris Nicholson-Sauls
Apr 11 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
 freeagle wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

what was wrong with "inout" ?

Got me. in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent. I can't say I understand the reason for a new keyword here.

The problem is just that 'const inout' doesn't make any sense. There's no 'out' about it if the thing is const. 'const ref' doesn't have that issue. Another solution to the 'const inout' conundrum might be to add 'in ref' or 'ref in'. I kinda like that. But I think 'in ref' would basically have to be declared a synonym for 'const ref'. Having synonyms like that is not so great. But I for one would rather declare my parameters as 'in ref' than 'const ref' if for no other reason than it's 3 letters shorter. :-) But it also seems to go better with in and out, which I presume aren't going away. Actually, y'know using a single word looks so much better to me than two for paramters: vector add(inref vector b, inref vector b) { . . . } vs vector add(const ref vector b, const ref vector b) { . . . } Somehow going from 3 word parameters to 4 word paramters seems to make it much less readable to me. I also feel like we're headed for a paramter system with a personality disorder that can't decide if it wants to describe the intent (in,out,inout) or the concrete implementation (ref,const). The problem is there are really 4 cases that matter, and one of them really requires that you specify an implementation detail. I guess to me something like (in,out,inout,inref) looks cleaner than (in,out,ref,const ref). --bb
Apr 11 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 Sean Kelly wrote:
 freeagle wrote:
 Walter Bright wrote:
 Bug fixes, some enhancements.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.1.011.zip

what was wrong with "inout" ?

Got me. in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent. I can't say I understand the reason for a new keyword here.

The problem is just that 'const inout' doesn't make any sense. There's no 'out' about it if the thing is const. 'const ref' doesn't have that issue.

I suppose it's a matter of interpretation. To me, 'inout' suggests that the parameter *may* be modified, not that it *will* be. If the type passed is const, then that type simply doesn't support the possibility for modification allowed by 'inout'. So long as the compiler can handle this via analysis (ensure that const parameters are not modified despite the 'inout' qualifier) then great.
 Another solution to the 'const inout' conundrum might be to add 'in ref' 
 or 'ref in'.  I kinda like that.  But I think 'in ref' would basically 
 have to be declared a synonym for 'const ref'.  Having synonyms like 
 that is not so great.  But I for one would rather declare my parameters 
 as 'in ref' than 'const ref' if for no other reason than it's 3 letters 
 shorter. :-)   But it also seems to go better with in and out, which I 
 presume aren't going away.

I was unaware that Walter was considering a reference qualifier for more general use. If that's the case, then 'ref' may indeed make sense. If not, I don't see any reason to to simply have 'inout'.
 I also feel like we're headed for a paramter system with a personality 
 disorder that can't decide if it wants to describe the intent 
 (in,out,inout) or the concrete implementation (ref,const).

Agreed. I like 'in', 'out', and 'inout' becuse they're internally consistent. 'ref' seems like the odd man out. Assuming 'inout' isn't deprecated, I will continue to use 'inout' for function parameters, and 'ref' in some other situations, as the design warrants. Though I'll admit that I hate having multiple keywords for the same thing. Sean
Apr 16 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 freeagle wrote:
 what was wrong with "inout" ?

Got me. in, out, and inout are already present in other languages (Ada and CORBA, IIRC), and the names seem internally consistent. I can't say I understand the reason for a new keyword here.

Because there are uses for reference variables other than function parameters. Those look definitely odd being marked as 'inout'.
Apr 11 2007
next sibling parent reply Derek Parnell <derek psych.ward> writes:
freeagle wrote:
 what was wrong with "inout" ?


Walter Bright wrote:
 Because there are uses for reference variables other than function 
 parameters. Those look definitely odd being marked as 'inout'.

I count ten different parameter passing scenarios but I can't see the D syntax for three of those. Have I got this right ...? Parameter passing cases: Mechanism Parameter Referenced Pre-Init D Syntax ---------+------------+------------+--------+-------------------- by value unmodifiable unmodifiable n/a final in by value unmodifiable modifiable n/a const in by value modifiable unmodifiable n/a ??? by value modifiable modifiable n/a in by ref unmodifiable unmodifiable n/a final ref by ref unmodifiable modifiable n/a const ref by ref modifiable unmodifiable no ??? by ref modifiable modifiable no ref by ref modifiable unmodifiable yes ??? by ref modifiable modifiable yes out -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Apr 11 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 freeagle wrote:
 what was wrong with "inout" ?


Walter Bright wrote:
 Because there are uses for reference variables other than function 
 parameters. Those look definitely odd being marked as 'inout'.

I count ten different parameter passing scenarios but I can't see the D syntax for three of those. Have I got this right ...?

I wouldn't worry about it just yet, as there still is some unresolved details.
Apr 11 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 11 Apr 2007 15:41:57 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 freeagle wrote:
 what was wrong with "inout" ?


Walter Bright wrote:
 Because there are uses for reference variables other than function 
 parameters. Those look definitely odd being marked as 'inout'.

I count ten different parameter passing scenarios but I can't see the D syntax for three of those. Have I got this right ...?

I wouldn't worry about it just yet, as there still is some unresolved details.

Ok ... I guess the details of the D syntax can wait, but have I got it right in that there are only ten possible parameter passing scenarios? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Justice for David Hicks!" 12/04/2007 9:18:43 AM
Apr 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 Ok ... I guess the details of the D syntax can wait, but have I got it
 right in that there are only ten possible parameter passing scenarios?

No, more than that!
Apr 11 2007
prev sibling parent reply Serg Kovrov <kovrov no.spam> writes:
Walter Bright wrote:
 Because there are uses for reference variables other than function 
 parameters. Those look definitely odd being marked as 'inout'.

And examples of such other uses are... ? to have something like: auto bar = ref foo; or ref bar = foo; instead of: auto bar = &foo; Is it that what you mean? -- serg.
Apr 11 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Serg Kovrov wrote:
 Walter Bright wrote:
 Because there are uses for reference variables other than function 
 parameters. Those look definitely odd being marked as 'inout'.

And examples of such other uses are... ? to have something like: auto bar = ref foo; or ref bar = foo; instead of: auto bar = &foo; Is it that what you mean?

Yes.
Apr 11 2007
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 11 Apr 2007, Charlie wrote:

 Serg Kovrov wrote:
 freeagle wrote:
 what was wrong with "inout" ?

Nothing. I hope 'inout' will stay "read-write reference" (&), and 'ref' will become "read-only reference" (const &). Although 'in' seems better name for it... But well, we'll see.

I second this , having one word to mean 'constant reference' would be far preferable to a 'const' qualifier, and leave inout to mean what its always meant. Charlie

A 'const' qualifier is coming. D can't live much longer without it. See past threads on digitalmars.D on what it's goin to mean. It will be significantly better than c++'s 'put const everywhere and ignore the shortcomings'. You can agree or not about the exact terms used, but I can guarantee that there will be people on every side of the debate. Again, see the past threads on this topic as mentioned above. Later, Brad
Apr 11 2007