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