D's greatest mistakes

[Steven Schveighoffer]

On Mon, 29 Nov 2010 11:19:29 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 11/29/10 10:12 AM, Steven Schveighoffer wrote:
>> On Mon, 29 Nov 2010 10:54:04 -0500, Nick Sabalausky <a at a.a> wrote:
>>
>>> "Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message
>>> news:op.vmxqi4kmeav7ka at steve-laptop...
>>>> On Sun, 28 Nov 2010 23:19:44 -0500, Jack <jt at overlook.biz> wrote:
>>>>
>>>>> The post "C#'s greatest mistakes" prompts/begs this post. Have at it,
>>>>> pick up the ball and run with it, don't be shy. I expect Walter and
>>>>> Andrei to answer (if Walter and Andrei so dare!) after others' posts
>>>>> have
>>>>> stopped or stagnated into that cesspool of threaded discussion that  
>>>>> is
>>>>> "the subthread" or "tangential thread" (which surely needs a rock
>>>>> anthem).
>>>>
>>>> As I understand this is a troll post, but still provoked some good
>>>> discussion, I'll throw in my biggest problem with D:
>>>>
>>>> lack of tail-const/immutable for classes.
>>>>
>>>
>>> I've heard this before, but I'm a little unclear. Can you give an
>>> example?
>>
>>
>> This is a tail-const pointer:
>>
>> const(int)* ptr;
>>
>> I can reassign ptr at will:
>>
>> ptr = &x;
>> ptr = &y;
>>
>> but I can't change what ptr points to:
>>
>> *ptr = 5; // error
>>
>> Because classes are references, just like pointers, I would like a way
>> to have a tail-const class reference. But it's not possible:
>>
>> const(C) myref;
>>
>> myref = a; // error, cannot change const myref
>>
>> You can have a tail-const pointer to a class reference:
>>
>> C myref;
>> const(C) *myrefptr = &myref;
>>
>> But a class is on the heap, and the reference 'myref' is on the stack,
>> so myrefptr is only usable locally. In order to keep the 'infinite'
>> lifetime property, I have to create a class reference on the heap, and
>> then return a pointer to *that*. Just try to create a class reference on
>> the heap.
>>
>> Not only that, but I now have to waste 16 bytes of heap space just to
>> have a tail-const class reference, *just because* the syntax is
>> incomplete. I find this unacceptable.
>>
>> -Steve
>
> Syntax is the main issue in implementing this feature. Due to the  
> implicit nature of reference semantics for classes, there was no syntax  
> to distinguish between the head and the tail when qualifying.

Syntax is the main issue, but another issue is Walter's patience -- he  
already has stated that he has no interest in entertaining new solutions  
because he's already wasted enough time on it.

>
> FWIW I just thought of this syntax. It might work but it's not intuitive:
>
> const()C tailConst;

I think this fails for the same reason const(C) meaning tail const and  
const C meaning full const failed -- with parentheses, const applies to  
whatever is in them, and the C reference is outside the parentheses.

I can't see any other way than creating a new 'keyword' to denote  
tail-const.  Whether this be library defined or compiler defined remains  
to be seen.

My favorite in recent times is:

@tail const(C) tailconst;

> Ultimately I believe we need to make Rebindable palatable. That would  
> have the nice side effect of enabling other proxy types.

I think if we get to that point, D will be much more adept at doing a lot  
of const things (such as ranges of const types).

The big hurdle is implicit casting IMO.  For example C and  
Rebindable!(immutable C) needs to implicitly cast to Rebindable!(const  
C).  Right now, builtins and arrays are the only type constructions that  
enjoy implicit casting to their tail-const counterparts.  Until we solve  
this, any library solution is going to be woefully inadequate.

-Steve