DMD 0.177 release

[Andrei Alexandrescu (See Website For Email)]

Thomas Kuehne wrote:
>> 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?

It's a type because the symbol "int" is already bound as a keyword. 
There's no way (to the best of my knowledge) to specify two adjacent 
non-keyword symbols in a template parameter list.

>> 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.

The more I think of it, the more I think it sucks :o).

> How would storageof handle the following:
> 
> mixin ident!(extern(C) inout float function(int)) foo;

C does not have lvalue return types.


Andrei