On Sat, 26 May 2007 22:35:30 -0700
Walter Bright <newshound1@digitalmars.com> wrote:

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

Maybe noconst, nofinal etc.. might be a better idea at the cost that that would introduce extra keywords.

Henning

-- 
GPG Public Key: http://keyserver.veridis.com:11371/search?q=0x41911851 Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851

> How about restricting keywords
How about /removing/ restricting keywords

On Sun, 27 May 2007 11:59:52 +0200
Frank Benoit <keinfarbton@googlemail.com> wrote:

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

ack. Default to const seems reasonable to me too.

Henning

-- 
GPG Public Key: http://keyserver.veridis.com:11371/search?q=0x41911851 Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851

For those of us who haven't read all the threads on this stuff... Is there a page I can go to and read about the planned changes to D for this stuff?

I guess I wonder which combinations of qualifiers would make sense as in, out, and inout parameters.  I'd then try to figure out how one would write out any of the variations and try to make the most common ones as short and understandable as possible.


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.

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.

So why not make globals 'const scope final' also.  'scope' in this case being the global program scope.  Many globals are initialised and then simply read from, the rest would be marked 'mutable' and would then indicate a variable that could change and in the case of multithreaded apps clearly indicate a variable which needed locking/protection.

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

Using 'mutable' where you want a mutable parameter/global doesn't look bizarre to me.  Do you have a specific example in mind where it looks 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.

Who are you testing it on?  Are they a) long time D users or b) new users to D, perhaps long time C++ users?  c) some other group?

> On a related note, "cstring" has received universal condemnation <g>, so
>    I'll just have to make "string" work.

Excellent.

Regan Heath

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

That was my thought, too, but that just confused things for others even more.

Dave 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.
>>
> 
> I can understand that concern, but who've you been bouncing the beta off of ("It seems to knock people for a loop")?

C++ people. I regularly go to the nwcpp meetings, and we like to talk about D afterwards <g>. The nwcpp people are experienced C++ programmers, and a lot of them are opinion leaders (for example, a number of them have regular C++ articles and papers published).

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

Yup. First impressions count, and C++ peoples' first impressions of that was just universally bad. After some explaining, they understood what was going on and the rationale, but still just thought the confusion just wasn't worth it.

BTW, the next D compiler will be an 'alpha' with this stuff in it, mainly to try these things out and see how they work in practice. If it just isn't going to work, we'll try and fix it.

Frank Benoit wrote:
> 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.

I think having to write:

	mutable int x;

instead of:

	int x;

just isn't going to please people.

janderson wrote:
> Walter Bright wrote:
>> 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 agree with this suggestion. I always insist on the most restrictions possible and relaxing restrictions on a case-by-case basis. This is what I call tight code :)

I understand scope within the function body but I do not understand scope for parameters. How does scope affect class references, arrays, and primitives (like int)?

Regards,

Myron.

Walter Bright wrote:
> Frank Benoit wrote:
>> 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.
> 
> I think having to write:
> 
>     mutable int x;
> 
> instead of:
> 
>     int x;
> 
> just isn't going to please people.

Maybe not.  It would please me; in C++ right now, I usually
have to write "int const x = ...;" whereas if the default
were the "safe" form I could write just "int x = ...;".
(As usual, "int" is just an example, of course.)

Writing

  var int x;

would be just fine by me; I find it more readable than
using "mutable" (and the C++ community already has a
similar-but-different meaning for mutable, as you know,
so using a different term might be helpful).

It's often been said that if C++ were being designed from
a clean start that const would be the default.  D has had
that clean start -- and has made various changes that C++
would make but cannot for backwards compatibility reasons.
It would be nice to make some more steps in the right
direction while D still has a _relatively_ small existing
user base and code base.

(One direction in which C++ and D are going in different directions is default definitions for special member functions; most of those involved in C++ would seemingly like fewer defined by default, whereas if I remember, D tends to define more, such as memberwise comparison.  C++ defined those that it has implicitly largely for C compatibility.  The best option, currently under discussion for C++, seems to be to allow users to explicitly request that normal forms of certain operations be provided or excluded.  But I digress.)

-- James