Regan Heath wrote:
> Bill Baxter Wrote:
>> Manuel König wrote:
>>> I second this.
>>>
>>> Doing it this way 'in' also keeps its expressive character of saying "Hey, I am only the input and not that bunch of scope const final!", which especially makes sense when compared to 'out' in terms of data flow. And dismissing all of 'scope const final' just requires you to declare your params as 'in', which will rarely be the case.
>> Does nobody quote any more?  What are you seconding?
> 
> Are you using a news reader which displays posts in threads?  When you're not it can be annoying to find a post with no quotation, I agree.

I use Thunderbird, but since the D groups have so much traffic, and since I read it from multiple different computers, I end up reading in sort-by-date mode so that all the recent stuff is at the bottom and easy to find.

Oh for the day when I can store my Thunderbird settings on the net.  I wonder if there's a Google Thunderbird Sync plugin on the way...

--bb

On Sun, 20 May 2007 14:53:54 -0400, Regan Heath wrote:

> Walter Bright Wrote:
>> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
>> 
>> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

...

> Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?
> 
> My reasoning is that I think 'scope const final' should be the default for parameters as it's the most commonly used and safest option for parameters.  People should use it by default/accident and should have to explicitly opt out in cases where it makes sense.  These cases would then be clearly, visibly marked with 'out', 'ref' etc

Thanks Regan, your proposal sits very comfortably with me.

I have no problems with adding the 'ref' (whatever) keyword in those cases
where an implicit 'in' (a.k.a. 'scope const final') causes the compiler to
complain.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/05/2007 9:59:51 AM

Derek Parnell wrote:
> On Sun, 20 May 2007 14:53:54 -0400, Regan Heath wrote:
> 
>> Walter Bright Wrote:
>>> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
>>>
>>> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.
> 
> ....
> 
>> Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?
>>
>> My reasoning is that I think 'scope const final' should be the default for parameters as it's the most commonly used and safest option for parameters.  People should use it by default/accident and should have to explicitly opt out in cases where it makes sense.  These cases would then be clearly, visibly marked with 'out', 'ref' etc
> 
> Thanks Regan, your proposal sits very comfortably with me.
> 
> I have no problems with adding the 'ref' (whatever) keyword in those cases
> where an implicit 'in' (a.k.a. 'scope const final') causes the compiler to
> complain.

The only thing I'm concerned about is having a way of specifying "not scope const final".  I'm happy to have "safe-by-default", but there should be a way to escape it.

Maybe lack of type annotations on an argument could be taken as "scope const final"; adding any annotations manually disables this (so if you use "const int foo", then it really means "const int foo" and not "scope const final const int foo".  Then, we can use "in" to mean "just in; nothing else."

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> 
> Derek Parnell wrote:
>> On Sun, 20 May 2007 14:53:54 -0400, Regan Heath wrote:
>>
>>> Walter Bright Wrote:
>>>> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
>>>>
>>>> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.
>> .... 
>>
>>> Why not make this implicit 'in' parameter 'scope const final' avoiding
>>> the need to explicity say 'in' everywhere?
>>>
>>> My reasoning is that I think 'scope const final' should be the default
>>> for parameters as it's the most commonly used and safest option for
>>> parameters.  People should use it by default/accident and should have
>>> to explicitly opt out in cases where it makes sense.  These cases
>>> would then be clearly, visibly marked with 'out', 'ref' etc
>> Thanks Regan, your proposal sits very comfortably with me. 
>>
>> I have no problems with adding the 'ref' (whatever) keyword in those cases
>> where an implicit 'in' (a.k.a. 'scope const final') causes the compiler to
>> complain.
> 
> The only thing I'm concerned about is having a way of specifying "not
> scope const final".  I'm happy to have "safe-by-default", but there
> should be a way to escape it.
> 
> Maybe lack of type annotations on an argument could be taken as "scope
> const final"; adding any annotations manually disables this (so if you
> use "const int foo", then it really means "const int foo" and not "scope
> const final const int foo".  Then, we can use "in" to mean "just in;
> nothing else."

Ideally, starting from a black slate I'd say 'inout' should remove the const/final/scope-ness, instead of what it does now which is to make the *pointer* to the object itself modifiable.

Then 'ref' could be used to mean 'i want to pass the pointer by reference'.

So....

void foobulate(MyObject o) {
   o = new Object(); // bad
   o.member = 42; // bad
}
void foobulate(inout MyObject o) {
   o = new Object(); // bad!
   o.member = 42; // ok!
}
void foobulate(ref MyObject o) {
   o = new Object(); // ok!
   o.member = 42; // ok!
}

But that's just my top-of-the-head reaction.  I'm sure there are ramifications that I haven't considered.

I just wouldn't like to see 'in' take on a meaning other than "this parameter is being passed _in_ and you shouldn't expect to be able to get any information _out_ using it"

If it has a meaning of "it's ok to modify the thing being passed in" then pretty much the only time it will be used is when you are interested in the modification, so basically 'in' would mean "we want to get something out", which is nonsensical.

--bb

Regan Heath wrote:
> Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?

It's a good idea, but then there needs to be some way to pass a mutable reference. Such as:

class C { int x; }
void foo(C c)
{
    c.x = 3;
}

That doesn't work if 'const' is the default. Using out or inout doesn't work either, as those have slightly different semantics (an extra level of indirection).

Bill Baxter wrote:
> I just wouldn't like to see 'in' take on a meaning other than "this parameter is being passed _in_ and you shouldn't expect to be able to get any information _out_ using it"

I also think that would be a disastrously confusing change from what people having been currently using 'in' for. It'd be like wearing those funny glasses that turn the world upside down.

On Sun, 20 May 2007 20:10:44 -0700, Walter Bright wrote:

> Regan Heath wrote:
>> Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?
> 
> It's a good idea, but then there needs to be some way to pass a mutable reference. Such as:
> 
> class C { int x; }
> void foo(C c)
> {
>      c.x = 3;
> }
> 
> That doesn't work if 'const' is the default. Using out or inout doesn't work either, as those have slightly different semantics (an extra level of indirection).

What about 'const ref' meaning that a reference is being passed and that reference is constant but not the data being referred to...?

 class C { int x; }
 void foo(const ref C c)
 {
      c.x = 3; // okay
      c = new C; // fail
 }

I know I wouldn't mind changing my code to do this. It is just a lot safer and I'd rather "get it right" now than some years down the road with D.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/05/2007 1:53:21 PM

Derek Parnell wrote:
> What about 'const ref' meaning that a reference is being passed and that
> reference is constant but not the data being referred to...?
> 
>  class C { int x; }
>  void foo(const ref C c)
>  {
>       c.x = 3; // okay
>       c = new C; // fail
>  }

The trouble is that ref adds an extra level of indirection, and it would be confusing to say that in this case it didn't.

Another option is to reuse 'inout' to mean 'mutable', since 'inout' is replaced by 'ref'.

Walter Bright wrote:
> Derek Parnell wrote:
>> What about 'const ref' meaning that a reference is being passed and that
>> reference is constant but not the data being referred to...?
>>
>>  class C { int x; }
>>  void foo(const ref C c)
>>  {
>>       c.x = 3; // okay
>>       c = new C; // fail
>>  }
> 
> The trouble is that ref adds an extra level of indirection, and it would be confusing to say that in this case it didn't.
> 
> Another option is to reuse 'inout' to mean 'mutable', since 'inout' is replaced by 'ref'.

...which is what my last message was suggesting.  Any reason why that wouldn't work?   There is the question of what would happen to "out" and how you'd get out behavior applied to the pointer rather than the value.

And while "mutable" is on the table, is D going to have a story for private mutable members that don't affect the interface?  Like the classic private mutable cache member in C++.

--bb

Walter Bright wrote:
> Regan Heath wrote:
>> Why not make this implicit 'in' parameter 'scope const final' avoiding the need to explicity say 'in' everywhere?
> 
> It's a good idea, but then there needs to be some way to pass a mutable reference. Such as:
> 
> class C { int x; }
> void foo(C c)
> {
>     c.x = 3;
> }
> 
> That doesn't work if 'const' is the default. Using out or inout doesn't work either, as those have slightly different semantics (an extra level of indirection).

At the risk of aggravating more people by adding Yet Another Keyword, how about 'const scope final' by default, with some negative keywords to undo it.

Like, say, unconst and unscope:

void foo(unconst C c)
{
    c.x = 3;
}

or why not use the ! operator, which already means 'not':

void foo(!const C c)
{
    c.x = 3;
}

Cheers,

Reiner