Walter Bright wrote:

> Jason House wrote:
>> This is the one thing that really bugs me about const... <snip>
> It's much simpler:
> 
> const(S) s; // can rebind s
> const S s;  // cannot rebind s

First of all, the docs don't explicitly talk about this.  That really HAS to get fixed.

Also, "const(char)*a" and "const(char*)a" having different reference types confuses me.  In both cases, I can assign to a, but can't assign to *a. They really look the same.  This should be documented too.

Probably on a related note, "const(char) a" allows assignment to a (it's "rebindable"), but as far as I can tell, value types simply get overwritten when changed.  I'd argue that such a definition is useless, confusing, error-prone, and should be a compile-time error.

Maybe the problem is that the storage class specification is too easily confused with other const declarations.  As much as it may draw tossing of rotten fruit at me, I think we need the final keyword.

Would it be safe to say that "const int* x;" and "final const(int*) x;" are
the same thing?  Similarly that "invariant int* y;" and "final
invariant(int*) y;" are the same thing?

I'd argue that const and invariant should never be a storage class.  At the risk of even more rotten fruit, this aligns well with the C++ interpretation of "const char*" as a function parameter.  Of course, if a function has a return type of const(char*), it makes total sense that it should be assignable to a variable.  I think it all works and should, in the end, be less confusing.

On 11/30/07, Jason House <jason.james.house@gmail.com> wrote:
> Would it be safe to say that "const int* x;" and "final const(int*) x;" are
> the same thing?  Similarly that "invariant int* y;" and "final
> invariant(int*) y;" are the same thing?

Under D2.007 you would be correct. I don't know if "final" has actually been dropped yet, but I'm assuming it has. It's certainly on its way out.


> I'd argue that const and invariant should never be a storage class.

That's the conclusion I came to.

Jason House wrote:
> I'd argue that const and invariant should never be a storage class.

But then you'd have to give up:
	const x = 3;

On 11/30/07, Walter Bright <newshound1@digitalmars.com> wrote:
> Jason House wrote:
> > I'd argue that const and invariant should never be a storage class.
>
> But then you'd have to give up:
>         const x = 3;

...unless you added an extra rule to re-introduce it. That's why I threw in rule (5) in my list of proposed changes. Let

    const x = y;

be syntactic sugar for

    const(typeof(y)) x = y;

without having to make const an attribute. See the full list of 5 on whatever thread it's on to see how it all might hang together if you went for it.

Walter Bright wrote:

> Jason House wrote:
>> I'd argue that const and invariant should never be a storage class.
> 
> But then you'd have to give up:
> const x = 3;

I've been thinking more and I don't really like the whole storage class thing anyway.  I posted in the "const ideas" thread with my latest thoughts.

In whatever situation, "const x = 3;" would be syntactically invalid under any scheme, so bolting it in to be a pure constant seems just fine. Personally, I'd never use it, but no language should ever be designed to be exactly what I'd use and include nothing else :)