On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
On Saturday, 9 March 2013 at 16:42:56 UTC, deadalnix wrote:
On Saturday, 9 March 2013 at 15:22:55 UTC, monarch_dodra wrote:
[..]
BTW, in regards to template constraints (not the rest), he
does have a point. We have raised the exact same issues here
on the boards more than once.
The more I think of it, the more this whole duck typing for
templates is probably a bad solution because we lack tool to
express « meta types ».
I'm starting to think so too.
On Saturday, 9 March 2013 at 18:46:23 UTC, Peter Alexander
wrote:
[..]
I suppose a better solution to this problem would involve
someway of specifying that random access ranges are a subtype
of input ranges, and the overload resolution would recognise
that the random access range version is preferable to the more
general version when available.
I wonder how would these "polymorphic concepts" work exactly.
The following is pseudo-code:
concept A1 {
void foo();
}
concept A2 : A1 { // A2 extends A1
void bar();
}
concept B1 {
void fun();
}
concept B2 : B1 {
void gun();
}
struct S1 implements A2 {
void foo() { }
void bar() { }
}
struct S2 implements B2 {
void fun() { }
void gun() { }
}
void dostuff(A1, B1)(A1 a, B1 b) { } // Overload-1
void dostuff(A2, B1)(A2 a, B1 b) { } // Overload-2
void main() {
S1 s1;
S2 s2;
dostuff(s1, s2); // calls the more specialized Overload-2
}
// But, if we add the following overload, then the above
// function call dostuff(s1, s2) doesn't know whether to
// call Overload-2 or, the equally specialized, Overload-3:
void dostuff(A1, B2)(A1 a, B2 b) { } // Overload-3
// And, if we add yet another, more specialized, overload,
// then the previous ambiguity goes away:
void dostuff(A2, B2)(A2 a, B2 b) { }
Yes, that is the idea. It seems really cool.
