const, final, scope function parameters

[Bill Baxter]

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