Bill Baxter wrote:
> Any ETA on an updated const article?
> I think this one is out of date since it still talks about final.
> http://www.digitalmars.com/d/const.html

Yes, I need to fix that.

Walter Bright wrote:
> Craig Black wrote:
>> Here's another idea.  If we reverse the meaning of const(X) then we could do this:
>>
>> const X x;  // all const
>> const(X) x; // data const, ref mutable
> 
> This is what we have now.
> 
>> X const x; // data mutable, ref const 
> 
> This breaks transitivity of const.

That's our goal. Other languages have the final keyword for this; we don't want to feel left out.

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.224.1196658519.2338.digitalmars-d@puremagic.com...
> On 12/3/07, Craig Black <craigblack2@cox.net> wrote:
>> Sorry if this is a stupid question, but if
>>
>> const XY
>>
>> means that both X and Y are const, then
>
> But it doesn't. I don't understand what you're saying. A statement like "const XY x;" would mean that x is fully const and of type XY. A statement like "const X Y x;" just won't compile.

I guess using X and Y is bad since you assume they are both types.. Am I wrong in assuming the following?

const X* x;

is not equivalent to

const(X)* x;

Thus const X is not always equivalent to const(X)

On Dec 3, 2007 2:34 PM, Craig Black <cblack@ara.com> wrote:
> I guess using X and Y is bad since you assume they are both types.. Am I wrong in assuming the following?
>
> const X* x;
>
> is not equivalent to
>
> const(X)* x;
>
> Thus const X is not always equivalent to const(X)

OK. Start again, You've misunderstood me. My X stands for /everything between the word const and the identifier being declared/. (Not literally the symbol "X").

So I would want "const X* x" to be interchangeable with "const(X*) x", since, in this case, /everything between the word const and the identifier being declared/ is "X*".

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.227.1196693680.2338.digitalmars-d@puremagic.com...
> On Dec 3, 2007 2:34 PM, Craig Black <cblack@ara.com> wrote:
>> I guess using X and Y is bad since you assume they are both types.. Am I wrong in assuming the following?
>>
>> const X* x;
>>
>> is not equivalent to
>>
>> const(X)* x;
>>
>> Thus const X is not always equivalent to const(X)
>
> OK. Start again, You've misunderstood me. My X stands for /everything between the word const and the identifier being declared/. (Not literally the symbol "X").
>
> So I would want "const X* x" to be interchangeable with "const(X*) x", since, in this case, /everything between the word const and the identifier being declared/ is "X*".

Right!  And the same principle can be applied to references as well.

So "const X x;"  could be interpreted to be interchangeable with "const (X x);"  (even though technically the latter that will not compile).

Thus your const X == const(X) rule holds with "const(X) x;" and "const X x;"

"Craig Black" <cblack@ara.com> wrote in message news:fj16ut$qgf$1@digitalmars.com...
>
> "Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.227.1196693680.2338.digitalmars-d@puremagic.com...
>> On Dec 3, 2007 2:34 PM, Craig Black <cblack@ara.com> wrote:
>>> I guess using X and Y is bad since you assume they are both types.. Am I wrong in assuming the following?
>>>
>>> const X* x;
>>>
>>> is not equivalent to
>>>
>>> const(X)* x;
>>>
>>> Thus const X is not always equivalent to const(X)
>>
>> OK. Start again, You've misunderstood me. My X stands for /everything between the word const and the identifier being declared/. (Not literally the symbol "X").
>>
>> So I would want "const X* x" to be interchangeable with "const(X*) x", since, in this case, /everything between the word const and the identifier being declared/ is "X*".
>
> Right!  And the same principle can be applied to references as well.
>
> So "const X x;"  could be interpreted to be interchangeable with "const (X x);"  (even though technically the latter that will not compile).
>
> Thus your const X == const(X) rule holds with "const(X) x;" and "const X x;"
>

Just to expound further, the pointer and reference syntax seems difference since the reference is implicit.  Just think of  "const X x;" as "const X& x;" and you will see that the same principle that applies to pointers should also apply to references.

On 12/3/07, Craig Black <cblack@ara.com> wrote:
> Just to expound further, the pointer and reference syntax seems difference since the reference is implicit.  Just think of  "const X x;" as "const X& x;" and you will see that the same principle that applies to pointers should also apply to references.

Yes, I think we're on the same page here. Of course, only classes have references. Structs don't, ints don't, etc., but for classes, my preference would be for all four of the following to be exactly equivalent:

    const C c;
    const(C) c;
    const C& c;
    const(C&) c;

(Which leaves open the possibility of "const(C)& c;" to mean mutable
ref to const data").

That's not the status quo, however

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.229.1196702116.2338.digitalmars-d@puremagic.com...
> On 12/3/07, Craig Black <cblack@ara.com> wrote:
>> Just to expound further, the pointer and reference syntax seems
>> difference
>> since the reference is implicit.  Just think of  "const X x;" as "const
>> X&
>> x;" and you will see that the same principle that applies to pointers
>> should
>> also apply to references.
>
> Yes, I think we're on the same page here. Of course, only classes have references. Structs don't, ints don't, etc., but for classes, my preference would be for all four of the following to be exactly equivalent:
>
>    const C c;
>    const(C) c;
>    const C& c;
>    const(C&) c;
>
> (Which leaves open the possibility of "const(C)& c;" to mean mutable
> ref to const data").
>
> That's not the status quo, however

That syntax would looks OK, but I think it also makes sense to make "const(C) c" equivalent to "const(C)& c;".  Walter said that this is how the syntax already works.  Am I misunderstanding something?

What I don't understand is why Walter and others think that "C const c" violates transitivitiy.  What do they mean by transitivity?

Craig Black wrote:
> "Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.229.1196702116.2338.digitalmars-d@puremagic.com...
>> On 12/3/07, Craig Black <cblack@ara.com> wrote:
>>> Just to expound further, the pointer and reference syntax seems difference
>>> since the reference is implicit.  Just think of  "const X x;" as "const X&
>>> x;" and you will see that the same principle that applies to pointers should
>>> also apply to references.
>> Yes, I think we're on the same page here. Of course, only classes have
>> references. Structs don't, ints don't, etc., but for classes, my
>> preference would be for all four of the following to be exactly
>> equivalent:
>>
>>    const C c;
>>    const(C) c;
>>    const C& c;
>>    const(C&) c;
>>
>> (Which leaves open the possibility of "const(C)& c;" to mean mutable
>> ref to const data").
>>
>> That's not the status quo, however
> 
> That syntax would looks OK, but I think it also makes sense to make "const(C) c" equivalent to "const(C)& c;".  Walter said that this is how the syntax already works.  Am I misunderstanding something?

We don't like the syntax. It makes a tiny bit of sense, with that description, but it's unintuitive and error-prone.

> What I don't understand is why Walter and others think that "C const c" violates transitivitiy.  What do they mean by transitivity?

"C const c" -> c is a pointer that cannot be reassigned, but you can modify its members.

This violates transitivity, the property that you cannot follow a series of const pointers/references and end up with something mutable. It is also useful, but it isn't useful as a public interface sort-of-thing; it's useful at a relatively small scope. Which is why Walter hasn't implemented it; he doesn't see enough of a benefit yet.

> "C const c" -> c is a pointer that cannot be reassigned, but you can modify its members.

Right.

> This violates transitivity, the property that you cannot follow a series of const pointers/references and end up with something mutable. It is also useful, but it isn't useful as a public interface sort-of-thing; it's useful at a relatively small scope. Which is why Walter hasn't implemented it; he doesn't see enough of a benefit yet.

If that is correct, then transitivity just seems like an artificial restriction for no reason.  It's not like we are violating some fundamental law here.  I still don't see a good reason  not to allow "C const c" syntax. To me, it's straightforward.  However, it may complicate the compiler implementation.  I wouldn't know.