Extended Type Design.

[Bruno Medeiros]

Daniel Keep wrote:
> 
> 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
> 

No, another way to solve that is to have 'final' be a type modifier as well:

   typeof(&foo)  --> (final Foo)*

This is essentially exactly like C++'s 'const'. (and like the 'rdonly' 
in my "hobbyist" design.)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D