Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> Kevin Bealer wrote:
>> I would prefer for the types passed to a template to carry a lot more 
>> info across, and let the user decide which parts to throw away.  You 
>> could call this a "strict" template, if you want backward 
>> compatibility (but it's early in D's template design so maybe we don't 
>> care).
>>
>> I'm thinking that this (current) syntax:
>>
>> template foo(T) {
>>    T plus(T x, T y) { return x + y; }
>> }
>>
>> would be equivalent to:
>>
>> strict template foo(T) {
>>     T.value plus(T.value x, T.value y) { return x + y; }
>> }
>>
>> In a 'strict' template the type "T" would carry a lot of baggage.  It 
>> would know if T was constant (as in a local "const int x = 10"), or a 
>> constant view (maybe) whether it is an lvalue, rvalue, literal, 
>> known-at-compile-time, static array, result of arithmetic, etc.
>>
>> I couldn't tell you the actual names and definitions of all of these 
>> attributes -- I imagine they could be added one at a time as the need 
>> arose, starting with an equivalent for "storageof".  
> [snip]
> 
> These are great points. The direction I hope to steer things in would be 
> to (backward-compatibly) continue matching types "lossily", but to also 
> give you the ability to pattern-match the extra info when you want.
> 
> The syntax that I am proposing does away with storageof and is very much 
> in spirit with the current D:
> 
> S int foo(S, T)(S T t) { }

Interesting.  So I suppose I could explicitly instantiate the template as:

    int i;
    foo!(const)( i );

If so, this seems great.

> So far we're only thinking of storage-like attributes, but a good deal 
> of information can be encoded under the loose declaration of "storage".

Definitely.


Sean