Extended Type Design.

[Chris Nicholson-Sauls]

Tyler Knott wrote:
> Bruno Medeiros wrote:
>>
>> Huh? Wait a second, but won't D have the same issue, albeit with 
>> 'final'? For example, suppose you have:
>>   final Foo foo;
>> then what is:
>>   typeof(&foo)
>> ?
>>
> 
> invariant Foo* or const Foo*, depending on whichever is most appropriate 
> for the situation.  I'd guess that invariant Foo* would be the default 
> because it's semantically closest to what is being expressed (a pointer 
> to immutable data), though const Foo* is also allowable because you 
> can't modify data through const pointers either.

As I understand, there will be an implicit cast of mutables to immutables, so assuming 
'const' appears under 'invariant' in this list, I would expect|hope it to be 'const Foo*' 
so that it is passable to either 'const' or 'invariant' typed parameters.  Ie:

final Foo foo;

void alpha (invariant Foo x) {...}
void beta (const Foo x) {...}

auto ptr = &foo;
alpha(*foo); // no problem regardless
beta(*foo); // an issue if ptr is invariant

Again, this is /if/ the casting rules will be as I think they will.  I'm just now starting 
to wrap my own head around it.

Presumably if I really /want/ it to be invariant, I could maybe do this?
invariant ptr = &foo;

Which would perform the mentioned implicit cast before assignment, discarding the 
potential 'const' view.

-- Chris Nicholson-Sauls