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
>>> 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?
> 

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

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

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'.

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.

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

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.

jcc7 wrote:
> == 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?
>> I think there was a thread entitled "AST macros" a month ago.
> 
> 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

> 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!

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.

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