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.

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.

I like the 'in' method myself.

> 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

Chris Nicholson-Sauls 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.
> 
> I like the 'in' method myself.
> 
>> 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

Hear hear :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

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.

I don't disagree here.

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

On this point, couldn't it be something like, if you define const, final or scope then the default "const final scope" is removed?

[snip]

"janderson" <askme@me.com> kirjoitti viestissä news:f3bijn$t1h$1@digitalmars.com...
> Walter Bright wrote:
> [snip]
>> 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.
>
> On this point, couldn't it be something like, if you define const, final or scope then the default "const final scope" is removed?
>
> [snip]

I find myself thinking that this might be a better way.

So something akin to this (for in-only parameters)

void foo(int bar) - bar is const final scope
void foo(in int bar) - bar is normal
void foo(const int bar) - bar is const
void foo(final int bar) - bar is final
void foo(scope int bar) - bar is scope
etc. with the combinations

Any specifier of {in|const|final|scope} cancels the const final scope
default of the parameter; mixing "in" with "const", "final" or "scope" is
no problem, since the only use for "in" is to cancel the default of
const final scope, while any of those three cancels the default and
toggles itself on.

(Basically, in and no specifier swap places compared to Walter's
suggestion.) 

Rioshin an'Harthen wrote:

> 
> "janderson" <askme@me.com> kirjoitti viestissä news:f3bijn$t1h$1@digitalmars.com...
>> Walter Bright wrote:
>> [snip]
>>> 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.
>>
>> On this point, couldn't it be something like, if you define const, final or scope then the default "const final scope" is removed?
>>
>> [snip]
> 
> I find myself thinking that this might be a better way.
> 
> So something akin to this (for in-only parameters)
> 
> void foo(int bar) - bar is const final scope
> void foo(in int bar) - bar is normal
> void foo(const int bar) - bar is const
> void foo(final int bar) - bar is final
> void foo(scope int bar) - bar is scope
> etc. with the combinations
> 
> Any specifier of {in|const|final|scope} cancels the const final scope default of the parameter; mixing "in" with "const", "final" or "scope" is no problem, since the only use for "in" is to cancel the default of const final scope, while any of those three cancels the default and toggles itself on.
> 
> (Basically, in and no specifier swap places compared to Walter's
> suggestion.)

I like this one, basically it's safe by default and saves typing in the most common case, it would also avoid the problem I see in c++ sometimes, that people don't write const because it's more typing. Walter please reconsider, const by default will be worth any initial hassle.

> I like this one, basically it's safe by default and saves typing in the most common case, it would also avoid the problem I see in c++ sometimes, that people don't write const because it's more typing. Walter please reconsider, const by default will be worth any initial hassle.

i still second that.
with save default: the compiler will force the user to make the param
mutable if needed.
without save default: it will not complain, when mutable is not needed.

"Chris Nicholson-Sauls" <ibisbasenji@gmail.com> wrote in message news:f3b74k$bbk$2@digitalmars.com...
>
> 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
>

Yes, I really like those :)

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

I can understand that concern, but who've you been bouncing the beta off of ("It seems to knock people for a loop")?

It seems that over in d.D.announce the response was the opposite (IIRC, most were in favor of 'in' by default, at least to try with 2.0 to start off with).

That said, I have a nagging suspicion you'd be right for the most likely people to try D.

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

Already suggested, but maybe consider making the 'in' mean what it does in 1.x, undecorated as 'final const scope', and any other specifier(s) overrides any default group (const would be just const, etc.)?

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

Perhaps we look at it from the wrong side.

If we want to change the D language to make it more const, the keywords 'const', 'invariant'... are probably the wrong choice.

How about restricting keywords and add their opposites: 'mutable', 'once' (write once) and then make every variable declaration const by default? Each variable/parameter needs to be made modifyable with modifiers if needed.