View mode: basic / threaded / horizontal-split · Log in · Help
November 30, 2007
Re: Invariant doesn't apply to declared symbols
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.
November 30, 2007
Re: Invariant doesn't apply to declared symbols
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.
November 30, 2007
Re: Invariant doesn't apply to declared symbols
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;
November 30, 2007
Re: Invariant doesn't apply to declared symbols
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.
November 30, 2007
Re: Invariant doesn't apply to declared symbols
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 :)
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home