The Status of Const

[Steven Schveighoffer]

On Mon, 16 Aug 2010 08:56:51 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-08-16 08:08:21 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> 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.
>
> Indeed. This reflects my opinion too.
>
> I'm not saying much about this issue right now because I feel it's no  
> use, or to be precise, so much time convincing is needed to bring  
> something useful I'd rather do something else. I've taken the route  
> where I'll wait until others (Andrei?) hit the same problems and put  
> enough pressure to force the design to be revisited. Hopefully this will  
> happen sooner rather than later.

Yeah, it's why I let it go before.  But I think in light of the new  
ability to use attributes, and the need for it in my own project  
(dcollections), I want to try and push it again.  I may even try my hand  
at compiler hacking...

Hopefully, Andrei will eventually get around to dealing with const in  
std.container and see what a mess it will become without some sort of  
tail-const for ranges.

> Same situation for @safe, same for pure, same for shared. Which means I  
> won't be adopting D2's most interesting features for some time.
>
>
>> 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.
>
> The idea's not bad, but I think it needs some improvments. For instance,  
> in a struct, I might want some members to be part of the tail and some  
> other not. I believe that should be allowed somehow.

What do you mean "not", meaning they are fully const?  Because you can't  
not apply const to references inside a const struct, that's logical const,  
and while it might be a nice feature, Walter has steadfastly refused to  
allow it.

If you do mean fully const, then I'm not sure why you'd want that.

-Steve