Digital Mars - digitalmars.D.announce

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → "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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → =?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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

↑ ↓ ← → 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

digitalmars.D.announce - DMD 1.011 release