Extended Type Design.

[Chris Nicholson-Sauls]

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.

-- Chris Nicholson-Sauls