const

[Jason House]

Walter Bright wrote:

> 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.

Ummm... no, I don't think you do.  I guess I have a secret fear that except
for exceptionally rare cases, invariant data will be pushed to the fringe
of D.  The problem is that it's very hard to declare any data as invariant,
and there's no implicit casts to invariant.  Excluding strings, it seems
like 99% of normal usage will involve normal or const data.  In most cases,
const occurs through an implicit cast.

For functions that won't change multiple arguments, the developer must
choose how to declare each argument.  For each, should it be const or
invariant?  Invariant will likely require an explicit (unsafe?) cast by the
caller.  Const denies the compiler some kind of optimization choice, but
allows the caller to use the function freely.  As a natural consequence of,
functions will be written to accept const data for each argument.

Extending this further, nearly all D code will be unable to take advantage
of the compiler optimizations... And fall short of the grand hopes for D,
missing the window of opportunity that multi-core provides. 

> 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) { ... }

That's a very specific problem that I know has been under your radar, and I
assume with time it'll get solved in a nice and clean way.


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

I don't know what you mean by that.