February 01, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025



--- Comment #10 from Stewart Gordon <smjg@iname.com> 2012-02-01 05:27:34 PST ---
(In reply to comment #9)
> For (T : int) to be preferred over (T), it must return a worse match level for the unspecialized parameter.  Currently it will return MATCHconvert for these parameters, and return MATCHexact only when there is a (matching) spec type.

So MATCHexact means "the pattern can be matched only by this exact set of arguments", and MATCHconvert means "this is one of various sets of arguments that can match this pattern".

But then, surely, it would be rejecting the instantiation as ambiguous, not picking the (A...) overload.

Really, it's a fundamental flaw in the compiler logic whereby it conflates two essentially orthogonal concepts: exactness and specialisation.

A correct template instantiation algorithm would:
- see which template patterns match the instantiation exactly
- if none, see which template patterns match with implicit conversions
- of all the matches, determine which is most specialised

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 01, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025



--- Comment #11 from yebblies <yebblies@gmail.com> 2012-02-02 00:42:20 EST ---
(In reply to comment #10)
> So MATCHexact means "the pattern can be matched only by this exact set of arguments", and MATCHconvert means "this is one of various sets of arguments that can match this pattern".
> 

No, MATCHconvert means 'match with implicit conversions'.  These are the same match levels used for normal function argument matching.

> But then, surely, it would be rejecting the instantiation as ambiguous, not picking the (A...) overload.
> 

Actually, (A...) is an alias parameter so it comes up as MATCHexact.  (There is a bug report about this somewhere).  Otherwise you would get an ambiguity error.  This is not what should be happening, non-variadic templates should be preferred over variadic ones.

> Really, it's a fundamental flaw in the compiler logic whereby it conflates two essentially orthogonal concepts: exactness and specialisation.
> 
> A correct template instantiation algorithm would:
> - see which template patterns match the instantiation exactly
> - if none, see which template patterns match with implicit conversions
> - of all the matches, determine which is most specialised

It's not that simple when you take multiple parameters, overloads, mixing explicit template parameters and deduced ones, etc

The ordering (exact match, const match, convert match, deduced match, variadic match, alias match, specialized match, etc) is complicated and the match system needs a redesign to cope with it.  Expanding the current match system will not necessarily solve the problem, as the different levels interact in weird ways. This is probably what will end up happening if a better solution is not found.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 01, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025



--- Comment #12 from Stewart Gordon <smjg@iname.com> 2012-02-01 06:39:13 PST ---
(In reply to comment #11)
> No, MATCHconvert means 'match with implicit conversions'.  These are the same match levels used for normal function argument matching.

int is a type.  T as a template parameter denotes exactly that - a type.  So what implicit conversion is being performed?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 01, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025



--- Comment #13 from yebblies <yebblies@gmail.com> 2012-02-02 01:51:55 EST ---
(In reply to comment #12)
> (In reply to comment #11)
> > No, MATCHconvert means 'match with implicit conversions'.  These are the same match levels used for normal function argument matching.
> 
> int is a type.  T as a template parameter denotes exactly that - a type.  So what implicit conversion is being performed?

None.  That's why it's a hack to use it to represent deduced args with no spec type.  That's why it causes problems...

If you really want to understand how dmd does template deduction and overload
matching have a poke around in template.c (deduceFunctionTemplateMatch and
matchArgs) and mtype.c (callMatch).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
1 2
Next ›   Last »