Frank Benoit wrote:
> 
> foreach( m; myCollection ){
>   C c = m.getC();
>   c.doA();
>   c.doB();
>   C c2 = m.getTheOtherC();
> }
> 

I think that, as defined before, immutable would mean that the doA, doB call would fail unless they do not affect state as well. What you seem to be talking about is "final" which is that the reference is immutable, but the instance is not.

If I am right, then your example would have to be rewritten as such:

foreach( m; myCollection ){
  var C c = m.getC();
  c.doA();
  c.doB();
  var C c2 = m.getTheOtherC();
}

but then you could update the value of "c" to point to another reference. Thus the semantic is too course. We are back to having const, final, invariant.

In Walter's proposal:

foreach( m; myCollection ){
  final C c = m.getC();
  c.doA();
  c.doB();
  final C c2 = m.getTheOtherC();
}

would do what you want. So are you suggesting that final be the default storage attribute?

Regards,

Myron.

Walter Bright Wrote:
> Regan Heath wrote:
> > Walter Bright Wrote:
> >>> Why can't we apply 'scope const final' to function parameters only?
> >> Because it knocks people for a loop - gives a bad first impression.
> > 
> > Have these people tried using it, in the beta itself?
> 
> No. But you can't get people to try something they take an instant dislike to.

I don't want to offend these people you're referring to but I find their attitude quite .. how to put this .. closed minded and suggest you find people more willing to try new things .. like me! and basically everyone here in the NG.

After all D is a new thing (relatively speaking) so everyone here is willing to try new things.  And I think the generaly consensus is that we're all willing to try this new 'const scope final' by default thing and see how it goes.

Regan Heath

> So are you suggesting that final be the default
> storage attribute?

Oh, so i have a wrong understanding of the discussion, sorry about that. I need to read more.

Regan Heath wrote:
> Walter Bright Wrote:
>> Regan Heath wrote:

> 
>>> Why can't we apply 'scope const final' to function parameters
>>> only?
>> 
>> Because it knocks people for a loop - gives a bad first impression.
>> 
> 
> Really?  Have these people tried using it, in the beta itself?  Or
> have you just explained it to them?  I would hope that once someone
> actually uses it, it would come quite naturally.

I agree.

As a matter of fact, I originally took it for granted.

Walter Bright wrote:
> It looks like making "const final scope" be the default for function parameters is going to be infeasible. The troubles are that:
> 
> 1) It seems to knock a lot of people for a loop, who will be assuming that an undecorated name would be like an undecorated name for a local or global variable.
> 
> 2) Having to turn off one of the const, final, or scope, introduces the need for some sort of "not" keyword, like mutable, !const, !final, etc. It comes off looking bizarre.
> 
> However, making "in" be equivalent to "const final scope" does seem to work fine, requires no new keywords, and doesn't seem to confuse anyone.
> 
> On a related note, "cstring" has received universal condemnation <g>, so   I'll just have to make "string" work.

I'm gonna repost my question in this thread:

What is the reasoning behind the idea of 'scope' being the default together with 'const' and 'final'? I understand (and agree) why 'final' and 'const' should be the default type modifiers for function parameters, but why 'scope' as well? Does it look like 'scope' would be more common than non-scope?



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Walter Bright wrote:
>> It looks like making "const final scope" be the default for function parameters is going to be infeasible. The troubles are that:
>>
>> 1) It seems to knock a lot of people for a loop, who will be assuming that an undecorated name would be like an undecorated name for a local or global variable.
>>
>> 2) Having to turn off one of the const, final, or scope, introduces the need for some sort of "not" keyword, like mutable, !const, !final, etc. It comes off looking bizarre.
>>
>> However, making "in" be equivalent to "const final scope" does seem to work fine, requires no new keywords, and doesn't seem to confuse anyone.
>>
>> On a related note, "cstring" has received universal condemnation <g>, so   I'll just have to make "string" work.
> 
> I'm gonna repost my question in this thread:
> 
> What is the reasoning behind the idea of 'scope' being the default together with 'const' and 'final'? I understand (and agree) why 'final' and 'const' should be the default type modifiers for function parameters, but why 'scope' as well? Does it look like 'scope' would be more common than non-scope?

Do a majority of the parameters you pass to functions get stored somewhere that will last beyond the scope of the function?  From what I understand scope on a parameter will not mean that class objects get passed on the stack, if that's what you're thinking.  They'll still be reference parameters, just it will be an error for the function to store that reference in a global or a local static variable.

So I guess that means most setter methods that take objects will have to declare away the scope part (or in Walter's current way be 'const' rather than 'in'), because storing a reference is their whole reason for being.

--bb

Bill Baxter wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> It looks like making "const final scope" be the default for function parameters is going to be infeasible. The troubles are that:
>>>
>>> 1) It seems to knock a lot of people for a loop, who will be assuming that an undecorated name would be like an undecorated name for a local or global variable.
>>>
>>> 2) Having to turn off one of the const, final, or scope, introduces the need for some sort of "not" keyword, like mutable, !const, !final, etc. It comes off looking bizarre.
>>>
>>> However, making "in" be equivalent to "const final scope" does seem to work fine, requires no new keywords, and doesn't seem to confuse anyone.
>>>
>>> On a related note, "cstring" has received universal condemnation <g>, so   I'll just have to make "string" work.
>>
>> I'm gonna repost my question in this thread:
>>
>> What is the reasoning behind the idea of 'scope' being the default together with 'const' and 'final'? I understand (and agree) why 'final' and 'const' should be the default type modifiers for function parameters, but why 'scope' as well? Does it look like 'scope' would be more common than non-scope?
> 
> Do a majority of the parameters you pass to functions get stored somewhere that will last beyond the scope of the function?  From what I understand scope on a parameter will not mean that class objects get passed on the stack, if that's what you're thinking.  They'll still be reference parameters, just it will be an error for the function to store that reference in a global or a local static variable.
> 
> So I guess that means most setter methods that take objects will have to declare away the scope part (or in Walter's current way be 'const' rather than 'in'), because storing a reference is their whole reason for being.
> 
> --bb

Hum, in my experience, I wouldn't say the majority of them get stored somewhere, but I wouldn't say the majority of them *don't* get stored either. I guess both cases are more or less equal (unlike const&final which are the majority), even if perhaps the scope case is slightly more common. However, being that both cases are similar occurrences, I would say that the default case should be same as not having a keyword. (i.e., the default case should be the same as not having scope). But this is very early opinion, I'm nowhere near sure.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Bill Baxter wrote:
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>> It looks like making "const final scope" be the default for function parameters is going to be infeasible. The troubles are that:
>>>>
>>>> 1) It seems to knock a lot of people for a loop, who will be assuming that an undecorated name would be like an undecorated name for a local or global variable.
>>>>
>>>> 2) Having to turn off one of the const, final, or scope, introduces the need for some sort of "not" keyword, like mutable, !const, !final, etc. It comes off looking bizarre.
>>>>
>>>> However, making "in" be equivalent to "const final scope" does seem to work fine, requires no new keywords, and doesn't seem to confuse anyone.
>>>>
>>>> On a related note, "cstring" has received universal condemnation <g>, so   I'll just have to make "string" work.
>>>
>>> I'm gonna repost my question in this thread:
>>>
>>> What is the reasoning behind the idea of 'scope' being the default together with 'const' and 'final'? I understand (and agree) why 'final' and 'const' should be the default type modifiers for function parameters, but why 'scope' as well? Does it look like 'scope' would be more common than non-scope?
>>
>> Do a majority of the parameters you pass to functions get stored somewhere that will last beyond the scope of the function?  From what I understand scope on a parameter will not mean that class objects get passed on the stack, if that's what you're thinking.  They'll still be reference parameters, just it will be an error for the function to store that reference in a global or a local static variable.
>>
>> So I guess that means most setter methods that take objects will have to declare away the scope part (or in Walter's current way be 'const' rather than 'in'), because storing a reference is their whole reason for being.
>>
>> --bb
> 
> Hum, in my experience, I wouldn't say the majority of them get stored somewhere, but I wouldn't say the majority of them *don't* get stored either. I guess both cases are more or less equal (unlike const&final which are the majority), even if perhaps the scope case is slightly more common. However, being that both cases are similar occurrences, I would say that the default case should be same as not having a keyword. (i.e., the default case should be the same as not having scope). But this is very early opinion, I'm nowhere near sure.

I think the ratio of stored vs not stored is probably very different for member functions and free functions.  I'm not sure I believe it's close to 50% for member functions[*], but it's certainly much higher than for the free funcs.  Presumably Walter's going through and making all the necessary changes to get Phobos working and from that he'll get some idea of how painful the changes are.  But Phobos doesn't have a lot of classes, so he may get a skewed view. :-/   Hopefully he'll take that into account.


[*] My logic is that it seems reasonable to have about a 50/50 mix of accessors and mutators.  None of the accessors will store anything.  And only some fraction of the mutators will, since only mutators taking reference types will be affected.  Value types are just copied so no scope problems.  Put another way, I think the things that will need to be un-scoped are the exact same things with which you have ownership issues in C++.  That's certainly not the majority of methods in my experience.

--bb

Chris Nicholson-Sauls wrote:
> Walter Bright wrote:
>> ...
>> On a related note, "cstring" has received universal condemnation <g>, so   I'll just have to make "string" work.
> 
> Or maybe something like:
> alias const( char)[] utf8  ; // or even u8string
> alias const(wchar)[] utf16 ; // or even u16string
> alias const(dchar)[] utf32 ; // or even u32string
> 
> -- Chris Nicholson-Sauls

+1 on the short forms, -1 on the long forms.

OTOH, this isn't that significant, as your implementation is quite short. :-)

Sill, if the names are to get used in library routines... then perhaps it is significant.