const debacle

[Steven Schveighoffer]

"Janice Caron" wrote
> The question is, is our scheme simple enough. It won't fly if it
> complicates the const system too much.

I agree.  But I think it actually makes the scheme more flexible in a way 
that makes it simpler.  For example, instead of 3 functions for constancy, 
there can be just one, making the code simpler, and the binary smaller even. 
Writing:

inout(T) f(inout(T));

is just as easy as:

const(T) f(const(T));

So from a usability standpoint, it is just as simple as const or invariant. 
And as you say, it's the same as any other const type, so you can declare 
aliases and temporary variables just as easily.

The complication comes with "Oh God, I now have 3 const types, which one do 
I choose?!"  But I think this is answered in one paragraph (inout is only 
available as a function parameter, so that is the only time where this 
becomes an issue):

If you wish to have a function parameter that supports mutable, const, and 
invariant at the call site, but is not mutable inside the function, and 
which dictates the return value constancy based on those arguments, use 
inout.  If you want a parameter to be required to be const or invariant, 
declare it that way instead.

Really, the most complicated part of this is the implementation of it in the 
compiler.  I think using it will be really simple and intuitive.

-Steve