Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Chris Nicholson-Sauls wrote:
> Bruno Medeiros wrote:
>> Tyler Knott wrote:
>>> Chris Nicholson-Sauls wrote:
>>>> 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:
>>>>
>>>
>>> Actually, I take back what I said in my previous post in this 
>>> thread.  Taking the address of a final variable should always result 
>>> in an invariant pointer.  The reason is that invariant references 
>>> require the data they reference to never, ever change whereas const 
>>> references expect the data they reference to be changed by other 
>>> non-const/non-immutable references to that data.  Obviously, since 
>>> const references can't guarantee the data they reference won't change 
>>> they can't be cast to immutable references at all, but because const 
>>> references can still guarantee they won't mutate the data they 
>>> reference immutable references can be freely cast to const references.
>>
>> Well, yes, but is 'invariant' transitive like const? I think it is 
>> (but I'm not sure, I'm getting a bit lost in the thread), and if it 
>> is, those semantics won't work. I.e., "typeof(&foo) " in my example 
>> can't be invariant anything.
>>
> 
> Actually, having thought over it a few times, what I would really expect 
> is not a "const pointer to a Foo", but rather a "const(pointer to a 
> Foo)"...
> 
> final Foo foo;
> 
> auto ptr = &foo; // const(Foo*)
> 
> Hmm.  Baffling.  I almost give up.

Don't. It's entirely understandable to be confused. Extremely little 
information has been given to date. Once that information will come in 
proper book format, it will be very easy to understand.

Andrei