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

[Andrei Alexandrescu (See Website For Email)]

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