The Status of Const

[Steven Schveighoffer]

On Fri, 13 Aug 2010 23:20:55 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 08/13/2010 06:35 PM, Walter Bright wrote:
>> Steven Schveighoffer wrote:
>>> I like how it reads naturally. I think it's also syntactically
>>> unambiguous. Walter, please give this one some attention, I'd love to
>>> see this fixed.
>>
>> This was endlessly discussed maybe 3 years ago. I probably invested over
>> a hundred hours in trying to make it work.
>>
>> It doesn't work.

Perhaps part of this is the reluctance to reexamine something which was  
hard to prove correct given the ideas at the time?

However, the idea is attainable.  For the simple fact that we have  
tail-const references in other parts of the language.  All that is missing  
is syntax.

>> It wasn't the syntax. There were many syntaxes proposed. The type system
>> loses its coherency with such a special case in it. Generic code has
>> weird problems, type deduction gets strange, types lose their
>> composability, etc.

The fact that all syntaxes proposed back then didn't cut the mustard does  
not mean that no possible syntax exists.  This is not NP != P.  Given that  
we have syntax that works for pointers, it's logical and reasonable to  
assume that some syntax can work for generic tail-constness of  
everything.  In fact, we had syntax that *worked* it was just confusing.

BTW, I like Tomek's idea with @tail const/immutable/shared.  It's not a  
special case, it's a generic case, you can apply it to any type.

>> But there is a solution:
>>
>> const(Object)* o;
>>
>> Yes, under the hood it's 2 levels of indirection. But it works, it
>> requires no special syntax, it is completely consistent with the rest of
>> how the type system works, there are no corner holes in it, etc.

It obviously doesn't work.  We wouldn't be discussing it if the group of  
people bringing fresh proposals who haven't seen the previous discussions  
weren't having issues with it.  The rest of us who were involved with the  
discussions are cynical not because the problem can't be solved, but that  
you have stated that no solution exists and you aren't willing to look at  
it any more.  The main problem with this hack is that the standard way to  
refer to a mutable class is with just a class reference.  That doesn't  
implicitly cast to a tail-const class reference pointer.  So anything that  
uses tail-const class references has to be specially constructed instead  
of just passing it.  You can't just pass &x because x is a stack variable,  
which could be escaped.  So you have to create a class reference on the  
heap, and then pass the address to it.  Just try creating a class  
reference on the heap.

In essence, you lose all the benefits of classes by making them tail-const  
with this method.

The pain of dealing with tail-const class references via pointers makes  
you just not use them, because they are so awkward and cumbersome,  
especially when you see how elegantly D deals with tail const in the rest  
of the language.

> Actually this is an even better solution:
>
> const(Scoped!Type)* o;

Wait, isn't this a pointer to data allocated on the stack?  I must be  
misunderstanding something...

> The only issue is that you need to know the static type... polymorphism  
> doesn't work with pointers.

Yeah, for classes, this is a big big problem.

For all those dmd hackers out there, I think we are stuck unless someone  
can create a dmd patch to show it can be done.  Without that, I think  
Walter is simply unwilling to look at any possible solutions, having spent  
so much time trying to make it work.  If we take his time/effort  
requirement out of the equation, it could be possible to get something  
through.  I might take up dmd hacking just to get this working.

-Steve