template <typename T>
concept HasMagma = requires(T l) { l.magma(); };

struct LavaMan {
  void magma() { std::cout << " LavaMan is throwing LAVA" << std::endl; }
};

struct FakeVulcano {
  void try_making_lava() { std::cout << " Making fake lava" << std::endl; }
};

void make_lava(HasMagma auto& lava) {
    lava.magma();
}

void make_lava(auto& lava_thing){
    lava_thing.try_making_lava();
}

int main() {
  LavaMan v;
  FakeVulcano l;
  make_lava(l);
  make_lava(v);
  return 0;
}

results in:

 Making fake lava
 LavaMan is throwing LAVA

Is there something equivalent in dlang, doesn't seem like d support specialized overload?

On Saturday, 27 May 2023 at 13:23:38 UTC, vushu wrote:

D solution is called template constraints.

On Saturday, 27 May 2023 at 13:42:29 UTC, Basile B. wrote:

Yes I know there is template constraint, but not with specialized overloading right?

so you need to use static if for checking if it hasmagma.

On Saturday, 27 May 2023 at 13:23:38 UTC, vushu wrote:

you can use: static if (__traits(hasMember, T, "magma"))

import std;

struct LavaMan {
  void magma() { writeln(" LavaMan is throwing LAVA"); }
}

struct FakeVulcano {
  void try_making_lava() { writeln( " Making fake lava"); }
}


// all the magic
void make_lava(T)(ref T lava_thing){
    static if (__traits(hasMember, T, "magma"))
        lava_thing.magma();
    else
    	lava_thing.try_making_lava();
}

int main() {
  LavaMan v;
  FakeVulcano l;
  make_lava(l);
  make_lava(v);
  return 0;
}

 Making fake lava
 LavaMan is throwing LAVA

On 5/27/23 9:50 AM, vushu wrote:

What is missing is an "else" thing.

So you have to repeat the constraint (as a negation) unfortunately.

e.g.:

struct LavaMan {
  void magma() { writeln(" LavaMan is throwing LAVA"); }
}

struct FakeVulcano {
  void try_making_lava() { writeln(" Making fake lava"); }
};

void make_lava(T)(ref T lava) if (hasMagma!T) {
    lava.magma();
}

void make_lava(T)(ref T lava_thing) if (!hasMagma!T){
    lava_thing.try_making_lava();
}

-Steve

On Saturday, 27 May 2023 at 16:38:43 UTC, Steven Schveighoffer wrote:

struct LavaMan {
  void magma() { writeln(" LavaMan is throwing LAVA"); }
}

struct FakeVulcano {
  void try_making_lava() { writeln(" Making fake lava"); }
};

void make_lava(T)(ref T lava) if (hasMagma!T) {
    lava.magma();
}

void make_lava(T)(ref T lava_thing) if (!hasMagma!T){
    lava_thing.try_making_lava();
}

I see thanks for the example :), I think this probably the closest equivalent i dlang.

On Saturday, 27 May 2023 at 17:49:27 UTC, vushu wrote:

struct LavaMan {
  void magma() { writeln(" LavaMan is throwing LAVA"); }
}

struct FakeVulcano {
  void try_making_lava() { writeln(" Making fake lava"); }
};

void make_lava(T)(ref T lava) if (hasMagma!T) {
    lava.magma();
}

void make_lava(T)(ref T lava_thing) if (!hasMagma!T){
    lava_thing.try_making_lava();
}

I feel like overload in that case make things harder to read

My example has less context switch, and hte logic is correctly understandable at first sight

Only one make_lava function

On Saturday, 27 May 2023 at 18:41:47 UTC, ryuukk_ wrote:

struct LavaMan {
  void magma() { writeln(" LavaMan is throwing LAVA"); }
}

struct FakeVulcano {
  void try_making_lava() { writeln(" Making fake lava"); }
};

void make_lava(T)(ref T lava) if (hasMagma!T) {
    lava.magma();
}

void make_lava(T)(ref T lava_thing) if (!hasMagma!T){
    lava_thing.try_making_lava();
}

It depends this example is quite small and a static if is sufficient, if you have a lot of cases it would make sense to split thing up into overloaded functions.
imagine you are writing a library for handling vector or matrices that has a common
add function. I just want to know the equivalent thing in dlang vs c++.

On Saturday, 27 May 2023 at 19:16:18 UTC, vushu wrote:

Even with a lot of cases you can simply call in each static if a (private) subfunction. I would always prefer this over overloads because it gets you a much cleaner API (I consider the constraint to be part of the function signature, which therefore can get very long and produces a lot of overloads that each only differ in the constraints). Also it becomes more and more obfuscated for which cases there is an overload and for which not.
A good (?!?) example of how bad this can get is the "to" template.