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 ambiguous call, but this is a pattern that comes up an awful lot. How to do it in D?

I've asked this before, and people say:

  void f(T)(T t) if(!isSomething!T && !isSomethingElse!T) {}

Consider that more overloads are being introduced by users spread out across many modules that define their own kind of T; this solution is no good.

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 just another form of specialisation, but it requires me to be explicit with the base functionality.

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 in lieu of a more precise match. This is obviously an ambiguous call, but this is a pattern that comes up an awful lot. How to do it in D?
>
> I've asked this before, and people say:
>
>   void f(T)(T t) if(!isSomething!T && !isSomethingElse!T) {}
>
> Consider that more overloads are being introduced by users spread out across many modules that define their own kind of T; this solution is no good.

To my knowledge there is currently no clean way of doing this.
The easiest workaround would be to introduce another name for the implementation.

then it would look like
void f(T)(T t) {
  static if (is(fImpl(t) == void)) {
    f(t);
  } else {
    // default impl here
  }
}

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 here
   }
 }

On 1 September 2016 at 18:44, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> 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 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 ambiguous call, but this is a pattern that comes up an awful lot. How to do it in D?
>>
>> I've asked this before, and people say:
>>
>>   void f(T)(T t) if(!isSomething!T && !isSomethingElse!T) {}
>>
>> Consider that more overloads are being introduced by users spread out across many modules that define their own kind of T; this solution is no good.
>
>
> To my knowledge there is currently no clean way of doing this. The easiest workaround would be to introduce another name for the implementation.
>
> then it would look like
> void f(T)(T t) {
>   static if (is(fImpl(t) == void)) {
>     f(t);
>   } else {
>     // default impl here
>   }
> }

This was my fallback plan, but it seems a bit shit.

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!

On 1 September 2016 at 19:16, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> 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 current langauge.
> Also overloading lot of templates with templates constraints will eat into
> your compile-time!

I know, but it's core language feature of D! Basically every function
in the std library has some constraints. It's critical for anything
range based...
Perhaps if concepts existed, it might be a more direct and less
computationally intensive mechanism to deal with it. I've been feeling
like that'd really simplify the situation a lot for quite a few years
now.

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 in lieu of a more precise match. This is obviously an ambiguous call, but this is a pattern that comes up an awful lot. How to do it in D?
>
> I've asked this before, and people say:
>
>   void f(T)(T t) if(!isSomething!T && !isSomethingElse!T) {}
>
> Consider that more overloads are being introduced by users spread out across many modules that define their own kind of T; this solution is no good.

Simply
void f(T)(T t)
{
   static if(isSomething!T)
   {
   }
   else static if(isSomethingElse!T)
   {
   }
   else
   {
   }
}

I personally hate overloads, especially if the condition has a fallback, so I like to see no condition in the function signature, what makes for a much cleaner API.
I have never seen what benefit could be gained from having overloads. I think they are a relict from languages without static if.

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 if the overloads have different parameters or return type, they may make sense. But they still uglyfy the API, so I try to avoid them - instead I use default parameters and template parameters what pretty much always works.

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 encourage your users to modify your function itself, they can no longer drop in a new version and have to do a merge.

Templates in general seem weak for libraries in D, which is a pain considering templates are one of the areas where the language otherwise excels.