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



Reply via email to