Extended Type Design.

Reiner Pope reiner at none.com
Sat Mar 17 00:10:38 PDT 2007


Andrei Alexandrescu (See Website For Email) wrote:
> Reiner Pope wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Reiner Pope wrote:
>>>> Andrei Alexandrescu (See Website For Email) Wrote:
>>>>
>>>>> We have talked about a design. In short, the intent is to define 
>>>>> three flavors of immutability:
>>>>>
>>>>> a) final - a simple storage class controlling the immutability of 
>>>>> the bits allocated for the symbol per se;
>>>>>
>>>>> b) const - type qualifier meaning an immutable view of an otherwise 
>>>>> modifiable data. const does not control the bits of the object, 
>>>>> only the storage addressed indirectly by it (transitively);
>>>>>
>>>>> c) "superconst" - denoted as "const!" or "super const": type 
>>>>> qualifier meaning that the data is genuinely unmodifiable.
>>>>>
>>>> Is there anything in your discussion about compile-time constants 
>>>> (the sort that you need for 'static if', etc) ? You spoke a while 
>>>> ago about improving compile-time evaluation syntax so that there 
>>>> would be no difference at the call  site between runtime and 
>>>> compile-time evaluation (like for regexps).
>>>
>>> I understand this is high on Walter's list.
>> Good to hear that.
>>
>>  The syntax discussed is:
>>>
>>> // dispatched when the pattern is known at compile time
>>> RegExpMatch match(const char[] p)(const char[] p, char[] text) {...}
>>> // dispatched when the pattern is a runtime string
>>> RegExpMatch match()(const char[] p, char[] text) {...}
>> That seems fine, but I can't help wondering, "why the 
>> double-declaration of p in the first instance?" and also, "why does 
>> the second instance of match even need to be a template?".
> 
> Good question. It must be a template by the pigeonhole principle: each 
> compile-time regex generates in theory different code, so you must have 
> as many distinct functions as strings.
> 

But how about the runtime implementation of match()? There's no code 
generation there...


> 
> That's not on the list yet. One thing at a time :o).
Sure thing. It's just that we've already got so much more after D 1.0 
that I can't help wanting more :o).

Cheers,

Reiner



More information about the Digitalmars-d mailing list