Extended Type Design.

[Andrei Alexandrescu (See Website For Email)]

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Alex Burton wrote:
>>> Andrei Alexandrescu (See Website For Email) Wrote:
>>>
>>>> Walter Bright wrote:
>>>>> Derek Parnell wrote:
>>>> [snip]
>>>>>>> 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.
>>>> By the way, "invariant" is a lifesaver. Everybody and their sister 
>>>> in the coffee shop liked it at the first sight. The girl at the 
>>>> counter asked for kris' email :o).
>>>>
>>>> Yes, "invariant" is essentially a synonym to "constant", but here 
>>>> are two simple mnemonic devices to remember which is which:
>>>>
>>>> a) "const" is shorter because it's used more often;
>>>>
>>>> b) "const" is similar to C++'s homonym.
>>>>
>>>> Easier to remember than perl's $|.
>>>>
>>>>
>>>> Andrei
>>>
>>> Another option I'd like to have at least considered is the finding of 
>>> a character that can be used to denote const.
>>> Adding various constnesses to all the code could easily add a whole 
>>> lot of typing to the task of getting things done in D.
>>>
>>> Could we find a unicode character that wouldn't be too much trouble 
>>> for editors to insert ? Might mean that D starts to require unicode 
>>> source - but is that such a bad thing ?
>>>
>>> Are there any ascii characters that can be found that wont confuse 
>>> the parser ? - like how the use of ! works for templates
>>
>> Type inference will reduce the need for littering code with "const" a 
>> great deal (when compared to today's C++ code, at least). You just write:
>>
>> auto var = expression;
>>
>> and the const will propagate. Initial experience will show whether 
>> this is enough.
> 
> What about the ability to deduce only parts of a type?
> 
> Declaring types is also a kind of documentation / assertion that can 
> help maintainers of the code later.   I might want to specify const and 
> let the type be deduced, or I might want to specify the type I'm 
> expecting and let const be deduced.
> 
> Maybe declaration followed by is-test will be necessary for those cases. 
>  If they aren't too common I guess that's ok.  But I would hate to see
>    auto var = expression;
>    assert(is(non_const_typeof(var)==Something));
> become a standard idiom.
> 
> ... how will one do that is() check for base type sans type constructors?

assert(is(const typeof(var) == typeof(var)));

Only time will show whether this will be needed frequently. I don't 
think so: in general var will engender an error upon first mutation, 
which is close to its definition.

Andrei