Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Don Clugston wrote:
>>> It's better than super const. However:
>>> (1) I would want to go through all my existing D code and change 100% of my usages of 'const' to 'invariant'.
>>
>> Great to hear that!
> 
> Sorry, I didn't explain myself very well. I meant that this proposal breaks 100% of all existing D uses of const.

Ah, so I /did/ read that right.

>  >> (3) I concede the problem of association with 'readonly' and ROM. But
>>> the association between 'const' and 'constant' is pretty strong.
>>
>> I think there's universal agreement that you can't express tersely the two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". Probably it's best to just go with two terms and move on.
> 
> I completely agree with this. The gripe I have is that 'const' is a completely inappropriate term for 'const-as-in-C++'. It's a bizarre misnomer to use 'const' to mean "don't touch". The only benefit (albeit a considerable one) of this nomenclature is compatibility with C++ nomenclature, especially the term "const correctness".
> D currently has a 'const' which actually means "constant", it seems dreadful to exchange that for a clearly inferior "don't touch" meaning.
> I'm concerned that you may have spent so much time in C++ that you've become accustomed to "const" == "don't touch"; all of my previous posts have been arguing that this is a grossly unnatural association.

I completely agree with *that* :).

> It is possible that the C++ misnomer is so entrenched that D needs to perpetuate it, even at the expense of breaking all existing D code that uses 'const'.

And I really hope this is not the case.

> But then this really surprises me:
> 
>> final int a = 2;
>>
>> void f(final int b)
>> {
>> }
>> The choice of "final" in the second case prevents f from changing its argument,
>  > and it's the free will choice of f's author. The "final" does not
>  > influence f's signature or how other people use it.
>  > It's just constraining f's implementation.
> 
> because it seems that that we still have 'const' surprises for C++ refugees.

I don't see how this would be a surprise for anyone coming from C++. This is exactly how 'const' works for value types, isn't it? (Do this with reference types on the other hand, and I could see them being a bit confused)

The thing to keep in mind is that 'b' is a new variable (kept on the stack) that happens to have the same value as whatever was passed to the function. If that variable happens not to be changed by the code where it's in scope, that doesn't effect other code in any way at all.
In other words: There's no way to tell the difference from outside of the function, so why would it change the signature?

Don Clugston wrote:

> I completely agree with this. The gripe I have is that 'const' is a
> completely inappropriate term for 'const-as-in-C++'. It's a bizarre
> misnomer to use 'const' to mean "don't touch". The only benefit (albeit
> a considerable one) of this nomenclature is compatibility with C++
> nomenclature, especially the term "const correctness".
> D currently has a 'const' which actually means "constant", it seems
> dreadful to exchange that for a clearly inferior "don't touch" meaning.
> I'm concerned that you may have spent so much time in C++ that you've
> become accustomed to "const" == "don't touch"; all of my previous posts
> have been arguing that this is a grossly unnatural association.
> 
> It is possible that the C++ misnomer is so entrenched that D needs to perpetuate it, even at the expense of breaking all existing D code that uses 'const'.

I agree with Don here.

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

Frits van Bommel wrote:
> Don Clugston wrote:
>> But then this really surprises me:
>>
>>> final int a = 2;
>>>
>>> void f(final int b)
>>> {
>>> }
>>> The choice of "final" in the second case prevents f from changing its argument,
>>  > and it's the free will choice of f's author. The "final" does not
>>  > influence f's signature or how other people use it.
>>  > It's just constraining f's implementation.
>>
>> because it seems that that we still have 'const' surprises for C++ refugees.
> 
> I don't see how this would be a surprise for anyone coming from C++. This is exactly how 'const' works for value types, isn't it?

Yes. The point is that for some uses of C++ const, you have to use 'const', while for others you need to use 'final'. I feel that this weakens the argument for using the word 'const' in the C++ sense. The hypothetical C++ refugee is still going to have culture shock when using D const.

Derek Parnell Wrote:
> 
>   const char[] s;    // ok
>   ...
>   s[0] = 'a'; // fails
>   s    = "new data"; //ok
>   s.length = 2; // ok
> 

No, it can not.

const int[] a = [1, 2, 3, 4];
a.length = 2; // ok?
some_var = a[3]; // oops!

But length is not field.

jovo

jovo Wrote:

> Derek Parnell Wrote:
> > 
> >   const char[] s;    // ok
> >   ...
> >   s[0] = 'a'; // fails
> >   s    = "new data"; //ok
> >   s.length = 2; // ok
> > 
> 
> No, it can not.
> 
> const int[] a = [1, 2, 3, 4];
> a.length = 2; // ok?
> some_var = a[3]; // oops!
> 

Ooops! :)
May be it's more logical then I was thinking.

There are will be always tension between consistency,
convenience and efficiency of generated code.
Actually I like general D's approach.

jovo

Don Clugston wrote:
> Frits van Bommel wrote:
>> Don Clugston wrote:
>>> But then this really surprises me:
>>>
>>>> final int a = 2;
>>>>
>>>> void f(final int b)
>>>> {
>>>> }
>>>> The choice of "final" in the second case prevents f from changing its argument,
>>>  > and it's the free will choice of f's author. The "final" does not
>>>  > influence f's signature or how other people use it.
>>>  > It's just constraining f's implementation.
>>>
>>> because it seems that that we still have 'const' surprises for C++ refugees.
>>
>> I don't see how this would be a surprise for anyone coming from C++. This is exactly how 'const' works for value types, isn't it?
> 
> Yes. The point is that for some uses of C++ const, you have to use 'const', while for others you need to use 'final'. I feel that this weakens the argument for using the word 'const' in the C++ sense. The hypothetical C++ refugee is still going to have culture shock when using D const.

I think the shock will be mollified by the explanation that const is for the stuff "before the star" and final is for the stuff "after the star".

const char *const s = "hello"; // C++

Many C++ programmers complain about this syntax, finding it silly.


Andrei

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Don Clugston wrote:
>>> Assuming that 'invariant' = really constant, 'const' = C++ pseudo-const...
>>
>> Yah.
>>
>>> It's better than super const. However:
>>> (1) I would want to go through all my existing D code and change 100% of my usages of 'const' to 'invariant'.
>>
>> Great to hear that!
> 
> Sorry, I didn't explain myself very well. I meant that this proposal breaks 100% of all existing D uses of const.

I don't think so. Const becomes less precise, but maybe code wasn't using it with all the precision anyway. I actually suspect the new semantics will break very little code.

>  >> (3) I concede the problem of association with 'readonly' and ROM. But
>>> the association between 'const' and 'constant' is pretty strong.
>>
>> I think there's universal agreement that you can't express tersely the two notions "const-as-in-C++" and "const-as-in-we-really-mean-it". Probably it's best to just go with two terms and move on.
> 
> I completely agree with this. The gripe I have is that 'const' is a completely inappropriate term for 'const-as-in-C++'. It's a bizarre misnomer to use 'const' to mean "don't touch".

The problem is that we don't have a "nomer". Every good short name we considered would be as imprecise or more. There's no obvious choice that everybody's like, "those idiots! why did they _refuse_ to do it that way?" And it's telling that every single person who didn't like "const" with the intended meaning failed to come with an obviously better choice.

> The only benefit (albeit a considerable one) of this nomenclature is compatibility with C++ nomenclature, especially the term "const correctness".

Right. Imagine us coming with the "dontouch correctness" :o).

> D currently has a 'const' which actually means "constant", it seems dreadful to exchange that for a clearly inferior "don't touch" meaning.

It's not "inferior". If it were inferior, we'd take it out of the language. Today's "const" semantics are restrictive in ways that severely limit its usefulness (e.g. you can't pass data modifiable in a module to functions guaranteed to NOT modify data in another module). The new const will allow that, and that's great. It's not inferior.

> I'm concerned that you may have spent so much time in C++ that you've become accustomed to "const" == "don't touch"; all of my previous posts have been arguing that this is a grossly unnatural association.

I completely hear you. Yet you are failing to follow with, "...when it's so obvious to everyone that the natural association is..."

> It is possible that the C++ misnomer is so entrenched that D needs to perpetuate it, even at the expense of breaking all existing D code that uses 'const'.
> But then this really surprises me:
> 
>> final int a = 2;
>>
>> void f(final int b)
>> {
>> }
>> The choice of "final" in the second case prevents f from changing its argument,
>  > and it's the free will choice of f's author. The "final" does not
>  > influence f's signature or how other people use it.
>  > It's just constraining f's implementation.
> 
> because it seems that that we still have 'const' surprises for C++ refugees.

We can make "const" mean "final const" and drop "final", at the cost of disallowing correct code (e.g. functions that modify their own private parameters). Or we could come up with new syntax that puts "const" in a different position for array, e.g.:

void Fun(const char[] const s);

After considering such alternatives, final becomes much more attractive.


Andrei

Lars Ivar Igesund wrote:
> Don Clugston wrote:
> 
> 
>>I completely agree with this. The gripe I have is that 'const' is a
>>completely inappropriate term for 'const-as-in-C++'. It's a bizarre
>>misnomer to use 'const' to mean "don't touch". The only benefit (albeit
>>a considerable one) of this nomenclature is compatibility with C++
>>nomenclature, especially the term "const correctness".
>>D currently has a 'const' which actually means "constant", it seems
>>dreadful to exchange that for a clearly inferior "don't touch" meaning.
>>I'm concerned that you may have spent so much time in C++ that you've
>>become accustomed to "const" == "don't touch"; all of my previous posts
>>have been arguing that this is a grossly unnatural association.
>>
>>It is possible that the C++ misnomer is so entrenched that D needs to
>>perpetuate it, even at the expense of breaking all existing D code that
>>uses 'const'.
> 
> 
> I agree with Don here.


So do I

Was somewhat hoping invariant would be used in place of what has now taken shape as "const", and "constant" would be used in place of where "invariant" has landed. Then there would be no "const" to confuse anyone. Almost seems as though shortening the name by a couple of bytes is actually more important than the meaning of the words in use?

I'm not sure about "breaking all existing D code" ... there would seem to be very little use of "const" at this time, because the current semantics are really kinda worthless; e.g. one should probably use enum for most things 'constant', except you can't have "enum : char[]" making enum notably less useful than it could otherwise be.

Where does enum fit in this picture anyway? Can it recover some duty from "const" and/or "final" in a logical and consistent manner?

kris wrote:
> Lars Ivar Igesund wrote:
>> Don Clugston wrote:
>>
>>
>>> I completely agree with this. The gripe I have is that 'const' is a
>>> completely inappropriate term for 'const-as-in-C++'. It's a bizarre
>>> misnomer to use 'const' to mean "don't touch". The only benefit (albeit
>>> a considerable one) of this nomenclature is compatibility with C++
>>> nomenclature, especially the term "const correctness".
>>> D currently has a 'const' which actually means "constant", it seems
>>> dreadful to exchange that for a clearly inferior "don't touch" meaning.
>>> I'm concerned that you may have spent so much time in C++ that you've
>>> become accustomed to "const" == "don't touch"; all of my previous posts
>>> have been arguing that this is a grossly unnatural association.
>>>
>>> It is possible that the C++ misnomer is so entrenched that D needs to
>>> perpetuate it, even at the expense of breaking all existing D code that
>>> uses 'const'.
>>
>>
>> I agree with Don here.
> 
> 
> So do I
> 
> Was somewhat hoping invariant would be used in place of what has now taken shape as "const", and "constant" would be used in place of where "invariant" has landed. Then there would be no "const" to confuse anyone. Almost seems as though shortening the name by a couple of bytes is actually more important than the meaning of the words in use?

I think the 5 letters to 9 letters a difference, especially when repeated many times. And again: invariant and const are synonims. Merriam-Webster lists "constant" as the first meaning of "invariant":

http://m-w.com/dictionary/invariant

> I'm not sure about "breaking all existing D code" ... there would seem to be very little use of "const" at this time, because the current semantics are really kinda worthless; e.g. one should probably use enum for most things 'constant', except you can't have "enum : char[]" making enum notably less useful than it could otherwise be.
> 
> Where does enum fit in this picture anyway? Can it recover some duty from "const" and/or "final" in a logical and consistent manner?

If I had my way, I'd make the language powerful enough to express enumerated types in stdlib, then I'd deprecate the built-in one.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
[snip]
>> Was somewhat hoping invariant would be used in place of what has now taken shape as "const", and "constant" would be used in place of where "invariant" has landed. Then there would be no "const" to confuse anyone. Almost seems as though shortening the name by a couple of bytes is actually more important than the meaning of the words in use?
> 
> 
> I think the 5 letters to 9 letters a difference, especially when repeated many times. And again: invariant and const are synonims. Merriam-Webster lists "constant" as the first meaning of "invariant":
> 
> http://m-w.com/dictionary/invariant

Yeah, I know. Except there's three flies in the ointment:

1) you've already suggested "const" won't get used all that much (or can be implied/inferred instead).

2) Then there's the question of whether "constant" is a more appropriate term for what "invariant" is slated to do.

3) Additionally, it may well be better to dump "const" altogether simply to alleviate potential confusion.

It's hardly a life or death scenario, yet the choices being made really do appear to be slanted towards "something" that just doesn't seem entirely sensible


>> I'm not sure about "breaking all existing D code" ... there would seem to be very little use of "const" at this time, because the current semantics are really kinda worthless; e.g. one should probably use enum for most things 'constant', except you can't have "enum : char[]" making enum notably less useful than it could otherwise be.
>>
>> Where does enum fit in this picture anyway? Can it recover some duty from "const" and/or "final" in a logical and consistent manner?
> 
> 
> If I had my way, I'd make the language powerful enough to express enumerated types in stdlib, then I'd deprecate the built-in one.

Would be good to make the type system more flexible and extensible, but that's getting away from the point: enum represents 'constant' values, so presumably has some bearing upon this discussion?