Extended Type Design.

[Daniel Keep]

Bruno Medeiros wrote:
> 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.
> 
> Let's suppose it's  const Foo*  (the less restrictive option). Even so,
> you will be restricting the type more than necessary, thus loosing some
> range of freedom. Because with  const Foo*  you can't change members of
> Foo*, while with final Foo, you can change members of foo. I.e.:
> 
>   final Foo foo;
>   foo.x = 2;   // ok
> 
>   typeof(&foo) fooptr = &foo;
>   (*fooptr.x) = 2;   // not allowed

I guess the only way to solve that is to parameterise const and invariant...

> final Foo foo;
> final invariant Foo bar;
> writefln("%s", typeinfo(typeof(&foo)));
> writefln("%s", typeinfo(typeof(&bar)));
>
> --> invariant(1) Foo
>     invariant(*) Foo

Honestly, I don't think that's going to happen :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/