Extended Type Design.

Daniel Keep daniel.keep.lists at gmail.com
Sat Mar 24 18:54:47 PDT 2007



Bruno Medeiros wrote:
> Daniel Keep wrote:
>>
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>> Bruno has answered your specific questions, so I'll take a more
>>>> general tack.
>>>>
>>>> A symbol is a name to which is 'bound' a value.
>>>>
>>>> static int x = 3;
>>>>
>>>> '3' is the value.
>>>> 'int' is the type.
>>>> 'x' is the symbol.
>>>> 'static' is the storage class.
>>>>
>>>> Here, we bind a new value to the symbol x:
>>>>     x = 4;
>>>>
>>>> A storage class originally meant where the symbol is stored, such as
>>>> in the data segment, on the stack, in a register, or in ROM. It's been
>>>> generalized a bit since then. The main way to tell a storage class
>>>> apart is that:
>>>> 1) a storage class applies to the symbol
>>>> 2) a type is independent of storage class, i.e. you cannot create a
>>>> type that is "pointer to static" or "array of extern". Storage classes
>>>> do not affect overloading, nor type deduction.
>>>>
>>>> 'invariant' and 'const' are type modifiers (aka type constructors),
>>>> which mean when they are applied to a type, a new type is created that
>>>> is a combination.
>>>>
>>>> 'invariant' is a guarantee that any data of that type will never
>>>> change. 'const' is a guarantee that any data of that type will never
>>>> be modified through a reference to that type (though other, non-const
>>>> references to that type can modify the data).
>>> So 'final' will be a storage class and not a type modifier? That's one
>>> of the questions I still have with regards to your design, because I'm
>>> not seeing how 'final' can also not-be a type modifier. In particular,
>>> again, what is
>>>   typeof(&foo)
>>> where foo is:
>>>   final Foo foo;
>>> ?
>>
>> I imagine it would be (invariant Foo*): an invariant pointer to a
>> reference to a Foo.  Since *no one* is ever allowed to change final
>> storage, then a pointer to it must be invariant.
>>
>>     -- Daniel
>>
> 
> No, that's not possible. It was mentioned before in another post:
> news://news.digitalmars.com:119/etv81l$m94$1@digitalmars.com
> Since invariant is (planned to be) transitive, then that typeof can't be
> (invariant Foo*), since the contents of foo can change (altough the
> immediate-value won't).

You are, of course, right.  Damnit.  Just when I thought I understood
all this... :(

	-- 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