Extended Type Design.

[James Dennett]

Derek Parnell wrote:
> On Sat, 17 Mar 2007 21:33:16 -0700, Walter Bright wrote:
> 
>> Derek Parnell wrote:
>>>> final
>>>  This applies only to assignments to Write-Once RAM locations. This can be
>>> done by either the compiler or at run time depending on the amount of
>>> knowledge the compiler has about the location's usage.
>> No. This applies to rebinding of a name:
>> 	final x = 3;
>> 	x = 4;		// error, x is final
>> i.e. final applies to the declared name, not the type.
>>
>>>> const
>>>  This is applied to declarations to prevent code in the same scope as the
>>> declaration from being able to modify the item being declared.
>> No. This means that it is a readonly view of data - other views of the 
>> same data may change it.
>> 	char[] s = "hello".dup;
>> 	const char[] t = s;
>> 	t[0] = 'j';	// error, const char[] is a readonly view
>> 	s[0] = 'j';	// ok
>> 	writefln(t);	// prints "jello"
>> 	t = s[1..2];	// ok, as t is not final
>> Note that const applies to the type, not the name.
>>
>>>> invariant
>>>  This is applied to declarations to prevent code in the same application as
>>> the declaration from being able to modify the item being declared.
>> Almost right. It isn't the declaration, but the *type* that is 
>> invariant. Invariant applies to the type, not the name.
>>
>>> As you can see, I'm confused as to how the qualifier effects which code is
>>> allowed to change which items. Even more so when it comes to reference
>>> items ... 'cos I'm not sure how to use these qualifiers to specify whether
>>> the reference and/or the data being referenced can be changed, and by whom.
>> 'final' is a storage class, like 'static'. It doesn't apply to the type 
>> of the symbol, only the symbol itself.
>> 'const' and 'invariant' apply to the type of the symbol, not the symbol.
> 
> I'm sure its just a terminology problem I'm having, but I still can't
> understand what you are trying to tell me. I'm sorry I'm so thick!
> 
> To me the word 'type' refers to the data type associated with a symbol -
> like 'int', 'float', 'char[]' , etc... So when you say "'const' and
> 'invariant' apply to the type" it sounds like you are saying that 'const'
> prevents a symbol from changing types - which doesn't make sense to me. In
> D, a symbol can never change types once it has been declared. 

It's just saying that "T" and "const T" are different types
(unless T was already const); they have different permitted
operations.

I'd have to say that I find Walter's ideas on const/final
to be rather... distinctive... and we've debated terminology
at some length but with no resolution.  It's his language,
he can use terms as he wishes.  It may impede communication.
This may be a case of "final" being a thing that Walter likes
to think of as a storage class rather than a type modifier
(though in a more general sense storage classes are just a
special/restricted case of type modifiers).

"final", I think, is a workaround for handling types
that are accessed through automatically-dereferenced
GC'd pointers in D.  The auto-deref property hides the
actual type of those pointers from us, so we can't const-
qualify them; we just end up adding const to the type to
which they point.  C++ doesn't work this way, and so
const does everything that final does and more in C++.
It's just different.  If you want indirection via a
reference/pointer, C++ makes you say so, but gives you
the chance to apply type modifiers to that pointer.  D
does it invisibly, but then requires extra syntax to be
able to stop the name being rebindable.

-- James