On Wed, 11 Apr 2012 10:33:26 -0400, Andrei Alexandrescu
wrote:
On 4/11/12 9:23 AM, Steven Schveighoffer wrote:
Essentially, you are still forcing this sequence:
int func(T)(T arg) if(constraint) {...}
int func(T)(T arg) if(!constraint) {...}
when the second line could just be:
int func(T)
On 4/11/12 9:23 AM, Steven Schveighoffer wrote:
Essentially, you are still forcing this sequence:
int func(T)(T arg) if(constraint) {...}
int func(T)(T arg) if(!constraint) {...}
when the second line could just be:
int func(T)(T arg) else {...}
I don't see the benefit of enforcing the else br
On Wed, 11 Apr 2012 07:42:54 -0400, Don Clugston wrote:
This is the way we used to do it, before we had template constraints.
Although it works OK in simple cases, it doesn't scale -- you need to
know all possible template constraints.
I would like to see something in the language conceptu
On 4/11/12 6:42 AM, Don Clugston wrote:
Incidentally, when all template constraints fail, the compiler could
check them all again, and tell you exactly which conditions failed...
Algorithm: We know that:
false = !constraint1() && !constraint2() && !constraint3().
break each constraints into to
On 10/04/12 21:45, H. S. Teoh wrote:
A lot of template code (e.g. a big part of Phobos) use signature
constraints, for example:
void put(T,R)(R range, T data) if (isOutputRange!R) { ... }
This is all nice and good, except that when the user accidentally calls
.put on a non-range, you ge
On 2012-04-10 21:45, H. S. Teoh wrote:
A lot of template code (e.g. a big part of Phobos) use signature
constraints, for example:
void put(T,R)(R range, T data) if (isOutputRange!R) { ... }
This is all nice and good, except that when the user accidentally calls
.put on a non-range, you
On 04/10/12 23:08, H. S. Teoh wrote:
> On Tue, Apr 10, 2012 at 10:13:29PM +0200, Artur Skawina wrote:
> [...]
>>// Give the user at least a chance to figure out what's wrong when a
>> template
>>// constraint doesn't match - print both the found and the expected types.
>>bool _ttmm(T,
H. S. Teoh:
except that when the user accidentally calls
.put on a non-range, you get reams and reams of compiler errors
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=7878
Bye,
bearophile
On Tue, Apr 10, 2012 at 10:13:29PM +0200, Artur Skawina wrote:
[...]
>// Give the user at least a chance to figure out what's wrong when a
> template
>// constraint doesn't match - print both the found and the expected types.
>bool _ttmm(T, E)() {
> pragma(msg, "\nExpected: '" ~
On 10 April 2012 22:45, H. S. Teoh wrote:
> A lot of template code (e.g. a big part of Phobos) use signature
> constraints, for example:
>
>void put(T,R)(R range, T data) if (isOutputRange!R) { ... }
>
> This is all nice and good, except that when the user accidentally calls
> .put on a n
Clever, I like it :)
On 04/10/12 21:45, H. S. Teoh wrote:
> This produces far more readable error messages when an error happens.
> But it also requires lots of boilerplate static if's for every function
> that currently uses isOutputRange in their signature constraint.
>
> So here's take #2:
>
> void put(T,R)(
A lot of template code (e.g. a big part of Phobos) use signature
constraints, for example:
void put(T,R)(R range, T data) if (isOutputRange!R) { ... }
This is all nice and good, except that when the user accidentally calls
.put on a non-range, you get reams and reams of compiler errors
co
13 matches
Mail list logo
