[Issue 1528] [tdpl] overloading template and non-template functions

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Feb 24 22:30:31 PST 2013


http://d.puremagic.com/issues/show_bug.cgi?id=1528



--- Comment #12 from Kenji Hara <k.hara.pg at gmail.com> 2013-02-24 22:30:26 PST ---
(In reply to comment #11)
> The more specialized overload always wins.
> 
> The constraint is not considered when evaluating which is "more specialized".
> (Because in general we cannot evaluate that.) The constraint only determines if
> an overload is to be considered - it does not determine ordering.

Thanks for quickly answer. So, the resolution result of f5 and f6 should be
same as f3, because they are identical when hide their constraints. Right?

But, there is still questionable. How to calculate "The more specialized
overload" between function template and non-template one? For example, try to
consider case for f3(1). That is:

1. Normal function version f3(int) will match exactly to one int argument.
2. Function template version will deduce T <- int, and then instantiated
function f3!(int) == void f3(int) will match _exactly_ to one int argument.

But, in general, template version is less specialized than non-template
version. So, there is something necessary for ordering.

---
Consider one another case for f4(1L). That is:

1. Normal function will match to one long argument with conversion
(MATCHconvert).
2. Function template version will deduce T <- long and then instantiated
function f4!long will match exactly to one long argument.

Which is specialized? In general, template version would be intended to pick up
non-exact matching for generic cases. But, as far as I infer from current dmd
implementation, f4(1L) will be ambiguous (template type parameter deduction
without specialization always be MATCHconvert).

Therefore, I'd ask question again to Walter: how does above cases behave?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list