On Friday, 19 November 2021 23:26:57 CET Jason Merrill wrote: > On 11/19/21 04:53, Matthias Kretz wrote: > > My motivation for printing a function template specialization differently > > is: > > > > 1. It's a different function definition that's being called. The user > > (caller) might be surprised to realize this is the case as he forgot > > about the specialization and was expecting his change to the general > > template to make a difference. > > > > 2. There's no T in > > > > template <> void f<int>() { > > // no T here, but of course I can define one: > > using T = int; > > } > > > > so presenting the function that was called as 'void f<T>() [with T = int]' > > is not exactly correct. In this case it wasn't even the case that T was > > deduced to be 'int', which we could argue to be useful information that > > might get lost. > > On the other hand, this tells us what template this specialization is > specializing, which could be unclear if there are multiple overloaded > function templates.
I don't disagree that printing the primary template + substitution has value. I just believe that being more explicit about a function specialization getting called has more value. But I guess we'll just have to live with our disagreement. I'll re-add the condition for "pretty-printing" specialized functions for the next patch revision, unless someone else wants to & can convince you. :) > There's always -fno-pretty-templates if you want the form without > template args. > > Incidentally, the contents of __PRETTY_FUNCTION__ probably shouldn't > vary with that flag... That ship is sailing since -fpretty-templates was implemented AFAICS. Do you want it to come back? ;) > >> That sounds good: omit defaulted parms only if they don't appear in the > >> signature (other than as another default template argument). > > > > Let me check whether I have the right idea: > > > > I could extend find_typenames (which walks the complete) tree to look for > > TEMPLATE_TYPE_PARM (and the 3 others I don't recall right now). But since > > that walks the *complete* tree, it'll simply find all parms with no > > indication > > whether they appear in the signature. Ideas: > > Hmm, since it walks DECL_TEMPLATE_RESULT, I wouldn't expect it to find > template parms that aren't in the function signature. Maybe I made an error elsewhere, but that's what I saw when I tried it. I'll try again (next week, I think). -- ────────────────────────────────────────────────────────────────────────── Dr. Matthias Kretz https://mattkretz.github.io GSI Helmholtz Centre for Heavy Ion Research https://gsi.de stdₓ::simd ──────────────────────────────────────────────────────────────────────────