Extended Type Design.
Daniel Keep
daniel.keep.lists at gmail.com
Thu Mar 22 18:08:44 PDT 2007
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/
More information about the Digitalmars-d
mailing list