digitalmars.D.bugs - [Issue 2025] New: Inconsistent rules for instantiating templates with a tuple parameter
- d-bugmail puremagic.com (44/44) Apr 22 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (12/12) Nov 21 2008 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (18/18) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (12/12) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (7/9) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (13/18) Jan 31 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (12/15) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (10/20) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (11/12) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (17/22) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (17/21) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (19/33) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (8/10) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
- d-bugmail puremagic.com (11/17) Feb 01 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2025
http://d.puremagic.com/issues/show_bug.cgi?id=2025 Summary: Inconsistent rules for instantiating templates with a tuple parameter Product: D Version: 2.012 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: samukha voliacable.com The template with non-tuple parameter is preferred if that parameter is a value (Case 1). The template with tuple parameter is preferred if the non-tuple parameter is a type (Case 2). Case 1 ---- template Foo(int i) { pragma(msg, "One"); } template Foo(A...) { pragma(msg, "Many"); } alias Foo!(1) foo; ---- Outputs: One Case 2 ---- template Foo(T) { pragma(msg, "One"); } template Foo(A...) { pragma(msg, "Many"); } alias Foo!(int) foo; ---- Outputs: Many Probably both cases should result in an ambiguity error. --
Apr 22 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2025 smjg iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smjg iname.com Keywords| |spec This is either wrong-code or accepts-invalid, but we need a clarification in the spec first. Compiler behaviour is most certainly wrong in case 2 - it leaves no way to instantiate the Foo(T) version. --
Nov 21 2008
http://d.puremagic.com/issues/show_bug.cgi?id=2025 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 01:30:32 PST --- Here's what's happening: Case 1 ------ 1 is an "exact" match with (int i) and (A...). Since (int i) is more specialized, it goes with (int i). Case 2 ------ int is a "convert" match with T (so that a better match would be Foo(T:int) and an "exact" match with (A...). The exact match wins. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 22 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025 timon.gehr gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timon.gehr gmx.ch (T:int) wins against (A...). Why can't the same be done for (T:int) vs (T) ? (A...) is certainly less specialized than (T), and int matches both equally well, therefore I think it is strange that (A...) would be chosen over (T). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 22 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025int is a "convert" match with T (so that a better match would be Foo(T:int) and an "exact" match with (A...). The exact match wins.You've lost me here. How is int matching T not exact? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 31 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.comAs Walter said, so that T:int would be considered a better match. It is a hack in the compiler that I'm not particularly fond of. See issue 4953 for another case it causes problems. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------int is a "convert" match with T (so that a better match would be Foo(T:int) and an "exact" match with (A...). The exact match wins.You've lost me here. How is int matching T not exact?
Jan 31 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025As Walter said, so that T:int would be considered a better match. It is a hack in the compiler that I'm not particularly fond of.What has a "better match" to do with anything? (int) matches the pattern (T) perfectly - no conversion, implicit or explicit. True, (T: int) is a more specialised match, but that doesn't magically render the match with (T) inexact.See issue 4953 for another case it causes problems.That's different - 5 is an int, so it doesn't exactly match the pattern (short x). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025What has a "better match" to do with anything? (int) matches the pattern (T) perfectly - no conversion, implicit or explicit. True, (T: int) is a more specialised match, inexact.more specialized == better match. That is how template type deduction works.but that doesn't magically render the match with (T)That's why I called it a hack.I know it's different, I wrote the patch for it. The hack causes problems there too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------See issue 4953 for another case it causes problems.That's different - 5 is an int, so it doesn't exactly match the pattern (short x).
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025more specialized == better match. That is how template type deduction works.But there's no (T : int) version of this template. We have two templates to match: Foo(T) and Foo(A...). Both patterns match Foo!(int) exactly, and Foo(T) matches a proper subset of everything that Foo(A...) matches. So Foo(T) is the most specialised match that the code has supplied. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025It doesn't matter. The compiler does template argument deduction through a function called matchArg in template.c. It will generate one of the match levels (MATCHnomatch, MATCHconvert, MATCHconst, MATCHexact) based on what the template parameter, spectype, and argument are. matchArg does not know or care what the other overloads of the template are, or even what the other arguments are. 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. Which leaves you with a non-exact match for (T) and (T...), even if it's the only overload. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------more specialized == better match. That is how template type deduction works.But there's no (T : int) version of this template.
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025For (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: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025So 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 specialisedIt'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: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025No, 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: -------
Feb 01 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2025None. 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: -------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?
Feb 01 2012