const

[Walter Bright]

Jason House wrote:
> What's novel about what I was posting is that I want a way to have
> polysemous constness...  A promise by the code writer to not modify
> the data, but saying *nothing* about what happens to the data outside
> of it's control.  It's different than the current const type where
> you won't assume the data is invariant.  Instead, it's saying that
> both const and invariant data is ok as an input and leaves it to be
> the compiler's job to do the right thing.
> 
> I may be adding a new type of const, but it's a lazier form that I
> believe many D users would prefer to use.  I'd expect this new type
> of polysemous const to be used very widely and push explicit
> declaration of an exact const format away from the every day user.
> 
> In effect, I'm increasing the const types the *compiler* has to worry
> about but reducing what an average D user has to worry about to one
> const type!

I understand what you're saying. It's simply finding a method of 
transferring the 'constness' of the function argument to the function 
return type, without changing the contents of the function.

Note that this is *not* a problem with const or invariant, it's a 
notational problem.

This is currently done in C++ (and D) by writing each function twice. 
Obviously, that is hardly ideal.

There have been some proposals to deal with it, but the current front 
runner is one Andrei came up with:

typeof(a) foo(const(T) a) { ... }

I'm worried it may have covariant/contravariant problems, but perhaps we 
can work that out.