D's greatest mistakes

[Steven Schveighoffer]

On Fri, 10 Dec 2010 13:00:01 -0500, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:

> On 09/12/2010 18:12, Steven Schveighoffer wrote:
>> On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros
>> <brunodomedeiros+spam at com.gmail> wrote:
>>
>>> On 29/11/2010 21:13, Steven Schveighoffer wrote:
>>>> On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin <spam at here.lot> wrote:
>>>>
>>>>> Steven Schveighoffer Wrote:
>>>>>
>>>>>> My favorite in recent times is:
>>>>>>
>>>>>> @tail const(C) tailconst;
>>>>>
>>>>> Tail const is a type constructor, but I don't think that annotations
>>>>> should evolve that far.
>>>>
>>>> What I liked about that is it is orthogonal to the constancy. That is,
>>>> with one annotation you get tail-const, tail-immutable, and  
>>>> tail-shared.
>>>>
>>>
>>> By saying that @tail is a type constructor, do you mean it can be
>>> applied to any const/immutable, anywhere they appear? Like, how do you
>>> declare a class var to be head-const and tail-immutable?
>>
>> @tail immutable(const(T))
>>
>>> Or an array of tail-const classes?
>>
>> @tail const(C)[]
>>
>> The @tail only applies to the modifier, not to the rest of it. It
>> modifies const.
>>
>
> Ok, what about a head-const array of tail-immutable classes?

const(@tail immutable(T)[])

> And would this be allowed: Foo!(@tail const(C)) ?

Yes.

>> BTW, this idea was shown to be too complex for use because of two
>> things: 1. the prospect of having to define both const and @tail const
>> member functions is way too complex for normal people, and 2. member
>> functions *always* pass the 'this' pointer by reference on a struct, so
>> you couldn't call for instance an immutable function on a tail-immutable
>> type.
>>
>> -Steve
>
> I was commenting on the syntax aspect only (because it actually seems  
> quite bad to me, not very orthogonal). And both issues above would apply  
> to any tailconst syntax, because they are really about tailconst itself.

Any tailconst system that allows applying tail-const to a non-reference  
type has the issues I mentioned.  That is why I'm not advocating for it  
anymore (gerically applicable tail-const that is).  I now think we need:

1. a syntax to make class references tail-const.  Michel Fortin has done  
this.
2. the ability to define implicit casting relationships between types that  
differ only on constancy.

That should give us the ability to define understandable types that can  
make defining custom constructs that enjoy the same tail-const benefits as  
builtin arrays.

-Steve