Extended Type Design.

Bruno Medeiros brunodomedeiros+spam at com.gmail
Mon Mar 19 08:31:03 PDT 2007


Andrei Alexandrescu (See Website For Email) wrote:
> 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

Why not just
   const auto var = expression;
?

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



More information about the Digitalmars-d mailing list