One of the comments written by Walter:

>Few programmers stuff so much on one line that it becomes difficult picking out the error.<

If you write D code in functional-style then lines of code often become quite long.

Bye,
bearophile

On 8/29/11, kennytm <kennytm@gmail.com> wrote:
> On the pattern matching syntax for templates in the comments -- Sigh, the spec gotta advertise this valid syntax in the operator overloading page more:
>
>     Foo opBinary(string op:"+")(...) { ... }
>

Wow I didn't know about this. So now I can do this:
enum Foo
{
    A,
    B
}

void test(Foo foo:Foo.A)()  {}

instead of the more verbose:
void test(Foo foo)()
    if (foo == Foo.A)
{}

On 29-08-2011 18:15, Andrej Mitrovic wrote:
> On 8/29/11, kennytm<kennytm@gmail.com>  wrote:
>> On the pattern matching syntax for templates in the comments -- Sigh, the
>> spec gotta advertise this valid syntax in the operator overloading page
>> more:
>>
>>      Foo opBinary(string op:"+")(...) { ... }
>>
>
> Wow I didn't know about this. So now I can do this:
> enum Foo
> {
>      A,
>      B
> }
>
> void test(Foo foo:Foo.A)()  {}
>
> instead of the more verbose:
> void test(Foo foo)()
>      if (foo == Foo.A)
> {}

Can it be used for overloading? I assume the way it works in that code is that it only runs the function if foo equals Foo.A.

- Alex

On 08/29/2011 06:30 PM, Alex Rønne Petersen wrote:
> On 29-08-2011 18:15, Andrej Mitrovic wrote:
>> On 8/29/11, kennytm<kennytm@gmail.com> wrote:
>>> On the pattern matching syntax for templates in the comments -- Sigh,
>>> the
>>> spec gotta advertise this valid syntax in the operator overloading page
>>> more:
>>>
>>> Foo opBinary(string op:"+")(...) { ... }
>>>
>>
>> Wow I didn't know about this. So now I can do this:
>> enum Foo
>> {
>> A,
>> B
>> }
>>
>> void test(Foo foo:Foo.A)() {}
>>
>> instead of the more verbose:
>> void test(Foo foo)()
>> if (foo == Foo.A)
>> {}
>
> Can it be used for overloading? I assume the way it works in that code
> is that it only runs the function if foo equals Foo.A.
>
> - Alex


Yes:
void test(Foo foo)() {}       // handles Foo.A
void test(Foo foo:Foo.B)() {} // handles Foo.B

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.

On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic <andrej.mitrovich@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.

On 08/29/2011 07:44 PM, Martin Nowak wrote:
> On Mon, 29 Aug 2011 18:55:56 +0200, Andrej Mitrovic
> <andrej.mitrovich@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) {}

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

Andrei

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

Yeah it's not important. But I'll definitely use the colon syntax more often now.