Talk:cpp/language/function template

Merging function/class template
Why two separate pages? Templates work mostly the same in classes and functions. -- Bazzy 10:12, 16 March 2012 (PDT)


 * These pages are probably just placeholders. Once we have some content, it would be much clearer whether the pages should be merged or not. My personal opinion is that there's a lot of information about templates, so it's probably beneficial to present it in several pages, though this may not apply to this case. Anyway, we'll see the big picture once the pages are filled.-- P12 19:00, 16 March 2012 (PDT)

Examples that compile
May I suggest that examples for this topic should be complete to be compiled too?

The major benefit is that you can easily test and try your understanding by making small modifications.

Surely it adds some lines but I think if done in a minimalistic way the core of each example will still be clearly visible - sew below:

Here is another one - if this style is acceptable, I'd volunteer to change all the examples in the topic's page accordingly.

Mwe (talk) 15:50, 26 May 2014 (PDT)


 * I feel that I went a bit overboard with the examples on this page: although they generally reflect what the standard found necessary to show in examples, a few should be dropped. In any case, the expected layout on this wiki so far has been is one compilable example in the end of the article, and occasional code snippets inline where necessary. Perhaps you're right, code snippets can be made compilable without adding too much bloat, I'd let others weigh in. --Cubbi (talk) 18:59, 26 May 2014 (PDT)


 * I'm okay with simple, short code snippets that do not compile -- I'd imagine that in that case, adding boilerplate to make the code compilable would do more harm than good, as it could interrupt the flow and obfuscate the point that's trying to be made. However, that argument doesn't hold up so well for longer examples. My feeling is there is some length threshold above which it makes sense to start making the examples compilable. For this page, maybe it would make sense to start with some longer examples and see how they look? --Nate (talk) 07:41, 27 May 2014 (PDT)

So that you can see here how it would look - these are the examples from the original page, with minor modifications to keep them short.

Please also note that after making this compile, two examples have not the outcome as described in their comments (I have marked them below).

So, no matter how this issue is decided, the topic page currently contradicts to the actual behavior and needs correction.

I did explicitely NOT show any output because the result is explained in the comment and the examples are mainly here for the reader to make small modifications and test his understanding.

-- Mwe (talk) 12:45, 27 May 2014 (PDT)

In the following examples, the fictitious arguments will be called U1, U2

I added some lines here to show how also #2 might be called unambigously (comment the currently ambigous call.)
 * I don't think the additions to this example are helpful. The focus was on one particular case where partial ordering fails and why. --Cubbi (talk) 15:15, 27 May 2014 (PDT)


 * I agree with this --Mwe (talk) 16:04, 27 May 2014 (PDT)

Since in a call context considers only parameters for which there are explicit call arguments, some parameters are ignored:

The following actually compiles though in its comment says the result is ambiguous.

The following actually compiles though in its comment says the result is ambiguous.

During template argument deduction within the partial ordering process, template parameters don't require to be matched with arguments, if the argument is not used in any of the types considered for partial ordering

Partial ordering of function templates containing template parameter packs is independent of the number of deduced arguments for those template parameter packs.


 * regarding "ambiguous (BUT ACTUALLY COMPILES with gcc-4.8 and clang-3.4" -- this is a C++ language reference, not any particular compiler reference. Don't get distracted by the bugs and language extensions available in the compilers provided by coliru. Those two examples, in particular, are directly from 14.5.6.2[temp.func.order]/5 --Cubbi (talk) 14:43, 27 May 2014 (PDT)


 * Specifically for this issue, compiler bug reports are gcc #41958 and clang #14372 --Cubbi (talk) 15:07, 27 May 2014 (PDT)


 * Thanks - I purposely put this here on the discussion page (only), this is no proposal it should go in the reference page, but (please correct me if I'm wrong): as I understand the discussion about core issue 1395 not preferring an ommitted parameter over a parameter pack (i.e. exactly what makes the first of the two examples ambiguous) has been identified as a language defect as it breaks a valid and useful pattern. Therefore we are not exactly talking about a broken compiler here. If I'm right, the question is whether we should reproduce this example uncommented because "it is as it is" if we only consider the words of the current standard or whether we rather should give a hint that compilers which do not identfify this as an ambiguity are simply forestalling an expected change of the language rules? --Mwe (talk) 16:04, 27 May 2014 (PDT)


 * It's fine to mention that in C++17, the behavior will be different due to CWG 1395, but there is currently nothing to back that up. Wait until the resolution is drafted, or better voted into the WP. --Cubbi (talk) 20:32, 27 May 2014 (PDT)