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

[Kevin Bealer]

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) { }
> 
> It does exactly what it says it does, in a clear and terse manner, and 
> is 100% within the spirit of existing D:
> 
> * It's customized on symbols S and T
> 
> * It's matching (by sheer position of S and T) the storage (i.e., all of 
> the gooey fuzzy nice information about the argument passed) and the type 
> of the incoming argument
> 
> * In this example it uses the storage in the result type (e.g. const 
> goes to const)
> 
> * Inside the function can easily use either T separately or S T as a 
> group that transports the storage around. You have total flexibility 
> (and don't forget that juxtaposition is always easier than extraction).
> 
> 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".
> 
> 
> Andrei

I like this; does this mean that when declaring an instance, you would 
do something like this?  Or do the 'const' parts get deduced?

alias Foo!(const, int) TheFoo;

Kevin