DMD 0.177 release

[Thomas Kuehne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrei Alexandrescu (See Website for Email) schrieb am 2006-12-20:
> Kevin Bealer wrote:
>> == Quote from Andrei Alexandrescu (See Website For Email)
>> ...
>>> That remains to be seen, but I think the buck stops at functions. The
>>> problem of duplicating templates for inout (lvalues) and rvalues
>>> stays, but I have an idea about that, that I might tell about
>>> tomorrow.

<snip>

> We then discussed another solution that I won't bore you with, as it's 
> so wrong it hurts. My current thoughts navigate around two possible 
> solutions. One is to make the storage part of the template parameters:
>
> template ident(S T) {
>    S T ident(S T e) { return e; }
> }
>
> When two adjacent symbols appear in a template parameter list, they 
> unambiguously denote a storage class followed by a type. So "S" can bind 
> to things like "in", "inout" etc., while "T" can bind to types.

Unambiguously?
 
template Templ_1(int i) {
}

Is "int" now a type or a storage class?

> Another solution that works is to commit to the idea of associating the 
> storage class with the parameter (and divorce it from the type 
> entirely). In that case, the following syntax describes what happens:
>
> template ident(T) {
>    storageof(e) T ident(storageof(e) T e) { return e; }
> }
>
> The storageof(symbol) meta-operator yields the storage of that symbol.

This seems to be much cleaner. How would storageof handle the following:

mixin ident!(extern(C) inout float function(int)) foo;

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFFiUIQLK5blCcjpWoRAo38AJwNP1gCk52kIKuto9x76paeQq1LewCfUbrK
zg3KJGIRH5wVoe/JeSR1aHE=
=0HhD
-----END PGP SIGNATURE-----