Consider: struct uniformInt(IntType) { static uniformInt opCall()(IntType min, IntType max); ResultType opCall(UniformRandomNumberGenerator) (ref UniformRandomNumberGenerator urng); } The compiler does not allow the overloading, although obviously the functions cannot be confused for one another. This is wrong at multiple levels. Since struct constructors are not allowed, static opCall is about the only decent way to create objects. So even if the parameter counts were the same, overloading should be allowed between static member functions and nonstatic member functions.
This doesn't seem to have anything to do with overloading. As I try it (DMD 1.023 and 2.007 alike, Windows) the code you've posted compiles without error. However, if I trying adding this code: void main() { uniformInt(2, 3); } then I get bz1623.d(2): struct bz1623.uniformInt(IntType) is not a function template bz1623.d(9): struct bz1623.uniformInt(IntType) cannot deduce template function f rom argument types (int,int) Nothing to do with overloading, but that it's a struct template, not a function template. If I cut down the example ---------- struct uniformInt(IntType) { static uniformInt opCall()(IntType min); } void main() { uniformInt(42); } ---------- then I get basically the same errors. What errors do you get when you try it under Linux?
I confirm this bug is still present in DMD 2.041. I expect it to be a major hindrance with the new operator overloading regime in which idioms like below are bound to get popular: struct Matrix { Matrix opOpAssign(string op)(real a); Matrix opOpAssign(string op)(Matrix m); } void main() { Matrix a; a += 3; } Error: template instance opOpAssign!("+=") matches more than one template declaration, opOpAssign(string op) and opOpAssign(string op)
Is this useful? struct Matrix { Matrix opOpAssign(string op, T:real)(T a); Matrix opOpAssign(string op, T:Matrix)(T m); }
(In reply to comment #3) > Is this useful? > > struct Matrix { > Matrix opOpAssign(string op, T:real)(T a); > Matrix opOpAssign(string op, T:Matrix)(T m); > } It is, thanks. Still, it'd be a lot cleaner to do without dummy template params... Is there some bigger problem that prevents the compiler to look at both template and runtime params when resolving templated function overloads? I'm guessing that it currently matches only against template signatures and bails out upon ambiguity.
The test case in comment 2 was fixed in DMD2.049 when bug 4430 was fixed. That seems to be the only valid test case in this bug report.