Extended Type Design.

Bill Baxter dnewsgroup at billbaxter.com
Sun Mar 18 10:49:39 PDT 2007


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?

--bb



More information about the Digitalmars-d mailing list