April 11, 2007
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
April 11, 2007
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
April 11, 2007
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!
April 11, 2007
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.
April 16, 2007
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
1 2 3 4 5
Next ›   Last »