Article about problems & suggestions for D 2.0

[Timon Gehr]

On 08/29/2011 08:59 PM, Andrei Alexandrescu wrote:
> On 8/29/11 1:39 PM, Timon Gehr wrote:
>> On 08/29/2011 07:44 PM, Martin Nowak wrote:
>>> On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
>>> <andrej.mitrovich at gmail.com> wrote:
>>>
>>>> Oh man wouldn't it be cool if we could use this syntax like this:
>>>>
>>>> void test(R1:isInputRange, R2:isForwardRange)(R1 r1, R2 r2) {}
>>>>
>>>> I'm not sure how that would work with multiple constraints or
>>>> constraints that need comparisons, e.g. ElementType:
>>>>
>>>> void test(R1:isInputRange && ElementType == int,
>>>> R2:isForwardRange)() {}
>>>>
>>>> Just throwing ideas for D5 there.. lol.
>>>
>>> Well, can you come up with a useful syntax for
>>> void put(E, R)(R r, E e) if(is(E : ElementType!R)) {}
>>> et.al.
>>>
>>> Otherwise having another syntax which put the sometimes heavy template
>>> constraints on the exact opposite
>>> side of the function signature is not too tempting.
>>
>> void put(E: ElementType!R, R)(R r, E e) {}
>
> The if-restriction on a template may build arbitrary expressions, so
> this case is addressed by pattern matching through "luck". So we
> definitely need if-restricted templates. Though I agree pattern matching
> syntax is nice, it is but an inferior alternative.
>

I am not sure that we are talking about the same thing. This does not 
actually compile now, because the compiler does never instantiate the 
template when performing pattern matching, so pattern matching only 
works with template structs/classes.

Andrej's suggestion was to actually allow arbitrary expressions:

Andrej Mitrovic wrote:
 > void test(R1:isInputRange && ElementType == int,
 > R2:isForwardRange)() {}

Basically, in an ideal world, it could be written more like this:

void test(R1: InputRange!int, R2: ForwardRange!_)() {}


But I don't consider that important. For me, guards are good enough to 
specify static duck typing interfaces.