Re: Fallback 'catch-all' template functions

Am Sat, 3 Sep 2016 02:56:16 -0700 schrieb Walter Bright : > On 9/3/2016 2:43 AM, Manu via Digitalmars-d wrote: > > This is interesting. Can you explain how that works? > > > Specializations are preferred over non-specializations, and T:T is the > identity >

Re: Fallback 'catch-all' template functions

Am Sat, 3 Sep 2016 14:24:13 +0200 schrieb Andrei Alexandrescu : > On 9/3/16 7:29 AM, Manu via Digitalmars-d wrote: > > On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d > > wrote: > >> On 9/3/16 2:41 AM, Manu via

Re: Fallback 'catch-all' template functions

On 9/3/16 6:10 PM, Manu via Digitalmars-d wrote: We do this sort of things a lot. Consider std.conv.to? std.conv.to is not a frequently done thing. -- Andrei

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 22:24, Andrei Alexandrescu via Digitalmars-d wrote: > On 9/3/16 7:29 AM, Manu via Digitalmars-d wrote: >> >> On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d >> wrote: >>> >>> On 9/3/16 2:41 AM,

Re: Fallback 'catch-all' template functions

On 9/3/16 7:29 AM, Manu via Digitalmars-d wrote: On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d wrote: On 9/3/16 2:41 AM, Manu via Digitalmars-d wrote: On 3 September 2016 at 00:18, Xinok via Digitalmars-d wrote:

Re: Fallback 'catch-all' template functions

On 9/3/2016 4:22 AM, Jacob Carlborg wrote: On 2016-09-03 11:56, Walter Bright wrote: Specializations are preferred over non-specializations, and T:T is the identity specialization. What if the compiler can prefer template constraint in the same way? Then perhaps this workaround could be

Re: Fallback 'catch-all' template functions

On 2016-09-03 11:56, Walter Bright wrote: Specializations are preferred over non-specializations, and T:T is the identity specialization. What if the compiler can prefer template constraint in the same way? Then perhaps this workaround could be avoided. -- /Jacob Carlborg

Re: Fallback 'catch-all' template functions

On 9/3/2016 2:43 AM, Manu via Digitalmars-d wrote: This is interesting. Can you explain how that works? Specializations are preferred over non-specializations, and T:T is the identity specialization.

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 19:19, Walter Bright via Digitalmars-d wrote: > On 8/31/2016 10:37 PM, Manu via Digitalmars-d wrote: >> >> So, consider a set of overloads: >> >> void f(T)(T t) if(isSomething!T) {} >> void f(T)(T t) if(isSomethingElse!T) {} >> void f(T)(T

Re: Fallback 'catch-all' template functions

On 9/3/2016 2:19 AM, Timon Gehr wrote: It had already been reported: https://issues.dlang.org/show_bug.cgi?id=11856 I have added this example to the report. Thank you!

Re: Fallback 'catch-all' template functions

On 03.09.2016 05:15, Walter Bright wrote: On 9/1/2016 10:49 AM, Timon Gehr wrote: The following causes an ICE (DMD segfaults). import std.stdio; int f(T)(T t) if(!__traits(compiles,.f!T)) { return 0; } int f(T)(T t) if(!__traits(compiles,.f!T)) { return 1; } void main(){

Re: Fallback 'catch-all' template functions

On 8/31/2016 10:37 PM, Manu via Digitalmars-d wrote: So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used in

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d wrote: > On 9/3/16 2:41 AM, Manu via Digitalmars-d wrote: >> >> On 3 September 2016 at 00:18, Xinok via Digitalmars-d >> wrote: >>> >>> >>> In the past, I have suggested

Re: Fallback 'catch-all' template functions

On 9/1/2016 10:49 AM, Timon Gehr wrote: The following causes an ICE (DMD segfaults). import std.stdio; int f(T)(T t) if(!__traits(compiles,.f!T)) { return 0; } int f(T)(T t) if(!__traits(compiles,.f!T)) { return 1; } void main(){ writeln(f(2)); } Please post seg faults to

Re: Fallback 'catch-all' template functions

On 9/3/16 2:41 AM, Manu via Digitalmars-d wrote: On 3 September 2016 at 00:18, Xinok via Digitalmars-d wrote: In the past, I have suggested using the "default" keyword to specify a fallback function of this kind. I think it's a useful pattern for generic

Re: Fallback 'catch-all' template functions

On 3 September 2016 at 00:18, Xinok via Digitalmars-d wrote: > > In the past, I have suggested using the "default" keyword to specify a > fallback function of this kind. I think it's a useful pattern for generic > algorithms that have optimized variants on specific

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 19:32:23 UTC, Timon Gehr wrote: Well, I'd argue that's not quite right and the correct interpretation is "If not the other X then this X", due to the `!__traits(compiles, .f!T)`, explicitly telling the compiler to check if the *other* "overloads" compile.

Re: Fallback 'catch-all' template functions

On 01.09.2016 21:02, Meta wrote: On Thursday, 1 September 2016 at 18:24:13 UTC, Timon Gehr wrote: The idea is that there'd only be one such "fallback" template, so that you cannot get into a situation such as this. I'm guessing the ICE is due to a recursive dependency between the two f

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 17:21:02 UTC, Meta wrote: I just thought of this, but cannot test if it works. If it does, maybe it would be a suitable solution? void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} //Taken if no other "overload" of f will intantiate

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 18:24:13 UTC, Timon Gehr wrote: The idea is that there'd only be one such "fallback" template, so that you cannot get into a situation such as this. I'm guessing the ICE is due to a recursive dependency between the two f templates? I posted the ICE to show

Re: Fallback 'catch-all' template functions

On 01.09.2016 19:55, Meta wrote: On Thursday, 1 September 2016 at 17:49:13 UTC, Timon Gehr wrote: On 01.09.2016 19:21, Meta wrote: ... I just thought of this, but cannot test if it works. If it does, maybe it would be a suitable solution? void f(T)(T t) if(isSomething!T) {} void f(T)(T t)

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 17:49:13 UTC, Timon Gehr wrote: On 01.09.2016 19:21, Meta wrote: ... I just thought of this, but cannot test if it works. If it does, maybe it would be a suitable solution? void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} //Taken

Re: Fallback 'catch-all' template functions

On 01.09.2016 19:21, Meta wrote: ... I just thought of this, but cannot test if it works. If it does, maybe it would be a suitable solution? void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} //Taken if no other "overload" of f will intantiate with the given T void

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 16:50:49 UTC, Steven Schveighoffer wrote: I agree. Note that if(isSomethingElse!T) may also need to have if(!isSomething!T && isSomethingElse!T). A suggestion in the past was to allow "else" clauses with if constraints. I had envisioned: void f(T)(T t)

Re: Fallback 'catch-all' template functions

On 9/1/16 1:37 AM, Manu via Digitalmars-d wrote: So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used in lieu of

Re: Fallback 'catch-all' template functions

On Thu, Sep 01, 2016 at 03:37:50PM +1000, Manu via Digitalmars-d wrote: > So, consider a set of overloads: > > void f(T)(T t) if(isSomething!T) {} > void f(T)(T t) if(isSomethingElse!T) {} > void f(T)(T t) {} > > I have a recurring problem where I need a fallback function like the > bottom

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 08:46:07 UTC, Stefan Koch wrote: On Thursday, 1 September 2016 at 08:44:38 UTC, Stefan Koch wrote: void f(T)(T t) { static if (is(fImpl(t) == void)) { f(t); } else { // default impl here } } Was meant to be void f(T)(T t) { static if

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 11:01:28 UTC, Dominikus Dittes Scherkl wrote: Ok, that may be fine, until you reach the point with the fallback version: if after that point someone "drops in" a new version, he silently changes the behavior of the function, because he "steals" some type which

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 10:50:18 UTC, Dominikus Dittes Scherkl wrote: On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes Scherkl wrote: I have never seen what benefit could be gained from having overloads. I think they are a relict from languages without static if. I

Re: Fallback 'catch-all' template functions

On 1 September 2016 at 20:43, Dominikus Dittes Scherkl via Digitalmars-d wrote: > On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: >> >> Consider that more overloads are being introduced by users spread out >> across many modules that define their own kind

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 10:53:01 UTC, Ethan Watson wrote: On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes Scherkl wrote: I have never seen what benefit could be gained from having overloads. Oh, it's perfectly fine if you're not writing a library that's designed to

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes Scherkl wrote: I have never seen what benefit could be gained from having overloads. Oh, it's perfectly fine if you're not writing a library that's designed to allow user extension by going the "all in one" method. If you

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 10:43:50 UTC, Dominikus Dittes Scherkl wrote: I have never seen what benefit could be gained from having overloads. I think they are a relict from languages without static if. I mean, overloads with same function signature except for the condition. Of course

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used

Re: Fallback 'catch-all' template functions

On 1 September 2016 at 19:16, Stefan Koch via Digitalmars-d wrote: > On Thursday, 1 September 2016 at 09:08:31 UTC, Manu wrote: >> >> >> This was my fallback plan, but it seems a bit shit. > > > Hmm I get your point. > But there is not really another way within the

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 09:08:31 UTC, Manu wrote: This was my fallback plan, but it seems a bit shit. Hmm I get your point. But there is not really another way within the current langauge. Also overloading lot of templates with templates constraints will eat into your compile-time!

Re: Fallback 'catch-all' template functions

On 1 September 2016 at 18:44, Stefan Koch via Digitalmars-d wrote: > On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: >> >> So, consider a set of overloads: >> >> void f(T)(T t) if(isSomething!T) {} >> void f(T)(T t) if(isSomethingElse!T) {} >> void

Re: Fallback 'catch-all' template functions

On 9/1/16, Manu via Digitalmars-d wrote: > So, consider a set of overloads: > > void f(T)(T t) if(isSomething!T) {} > void f(T)(T t) if(isSomethingElse!T) {} > void f(T)(T t) {} > Best thing I can think of is to use a forwarding template: - import

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 08:44:38 UTC, Stefan Koch wrote: void f(T)(T t) { static if (is(fImpl(t) == void)) { f(t); } else { // default impl here } } Was meant to be void f(T)(T t) { static if (is(fImpl(t) == void)) { fImpl(t); } else { // default impl

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used

Re: Fallback 'catch-all' template functions

On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote: I have a recurring problem where I need a fallback function like the bottom one, which should be used in lieu of a more precise match. +1. I've already hit this a few times with Binderoo. I would have assumed that constraints are

Fallback 'catch-all' template functions

So, consider a set of overloads: void f(T)(T t) if(isSomething!T) {} void f(T)(T t) if(isSomethingElse!T) {} void f(T)(T t) {} I have a recurring problem where I need a fallback function like the bottom one, which should be used in lieu of a more precise match. This is obviously an