how should function templates with explicit template arguments be exposed by C++ interop?

[zygoloid]

Summary of issue:

Example: std::make_unique expects to be passed a type as an explicit template parameter. We probably want a call such as Cpp.std.make_unique(MyType, arg1, arg2) to construct it from arg1, arg2. If so, how do we achieve that?

Details:

Probably the most obvious approach would be to say: if a template parameter is not deducible, then it must be explicitly specified in a call. That works for make_unique, and probably works fairly well in general, except for two things:

1. make_unique is overloaded. How should we handle the case where different overloads have different sets of non-deducible template parameters? Perhaps we could just reject such a call and ask for some explicit syntax to be used to indicate what the template arguments are.
2. While this may be a good default, it doesn't allow us to perform any call that's possible in C++, and doesn't give a way to override the default. One example where this comes up in practice in C++ is calls to std::min, where a deduced template argument is often fine, but sometimes you would want to call (eg) std::min<int64_t> because deduction would otherwise fail or pick the wrong type.

So perhaps we should additionally have some mechanism to explicitly specify the template arguments. If it's rarely used, I suppose it might be OK for it to be a little verbose. For example, we could use something like:

Cpp.std.min(Cpp.template(i32), 1, 2)

(where Cpp.template wraps a tuple of arguments so that the C++ call machinery knows to treat them as template arguments).

Any other information that you want to share?

No response

[danakj]

Another possibility: C++ templates that have non-deduced parameters are callable objects which can be passed the template arguments. Then it's Cpp.std.make_unique(i32)(1).

[zygoloid]

Another possibility: C++ templates that have non-deduced parameters are callable objects which can be passed the template arguments. Then it's Cpp.std.make_unique(i32)(1).

We should consider that. That would solve one problem not yet mentioned in this issue: given

template<typename ...T, typename ...U> void f(U ...u);

if we use the same argument list for both template arguments and function arguments, it's not clear where T ends and u begins in a call. I think the most prominent argument I see against that approach is that it would mean that calls to C++ function templates use different syntax than calls to Carbon generic functions.

We also would presumably still want to be able to use Cpp.F(args) in the case where all the template arguments of F are deducible, but we'd presumably also want a syntax for explicitly passing template arguments in that case.

[TechWizard9999]

I think this should be handled as a general language rule rather than a special case for make_unique.
The rule would be: -> if any template parameter is non-deducible, the call must provide explicit template arguments. There should also be a uniform syntax to explicitly pass template arguments even when deduction would normally work, to handle cases like std::min<int64_t>.
Something like Cpp.std.make_unique[i32](arg1, arg2) seems like a good fit. It is concise and keeps the call in a single expression rather than two chained calls. It also avoids overload ambiguity and works cleanly with variadic templates.
For cases where overloads differ in their non-deducible template parameters and no explicit arguments are provided, the compiler could simply emit an error asking the user to supply them explicitly.

[zygoloid]

@josh11b and I had a discussion about this. We identified three broad approaches:

1. Call syntax is always Function(args). We use some mechanism to identify where the transition from template arguments to function arguments is. This may involve adding some new syntax as a marker, or annotating the template arguments in some way.
2. Call syntax is Function(template args)(function args). We somehow identify in which cases Function(args) is specifying template arguments and in which cases it's specifying function arguments.
3. Call syntax is Function[template args](function args).

There are a number of factors that affect the decision here:

• We want a syntax that doesn't make C++ functions look different from Carbon functions. This suggests the first option. The second one is something that could be built in Carbon, but would be a little strange. The third one creates a false affordance: it suggests that you could use Function[args](args) to call a Carbon generic function, passing in arguments for the parameters declared in [...], which is explicitly something we do not want to support.
• We want a syntax that handles a trailing template argument pack, and we want to be able to support calls to overloads where different overloads take different numbers of template arguments. These rule out my suggestion from the issue description of working out the expected number of template arguments by examining the callee.
• We want all possible C++ calls to be representable. This is problematic for the second option, as it would likely mean that you must always use two sets of parens when calling any templated function, just in case you want to supply explicit template arguments -- or that you need a different syntax to opt into passing template arguments when we guessed that you would not do so.
• We want our mapping from Carbon syntax to C++ call to be stable under changes to the C++ code -- in particular, adding or removing functions or function templates in the overload set that aren't the one being called should not change the behavior. This again makes any analysis based on the contents of the overload set problematic.
• We do not want an ergonomic cost to passing explicit template arguments in most cases. For example, we could require a ref-like marker, say, template, on each explicit template argument, but calls to, for example, Cpp.std.make_unique(template i32) would be more cumbersome than is desirable.

The best option we found given the above constraints is to use the first approach, and to determine which arguments are template arguments based on their types, as follows:

• Each argument is classified as either "definitely a template argument" or "unknown".
• The sequence of template arguments is all arguments up to and including the last "definitely a template argument".
• An argument is classified as "definitely a template argument" if it is of type type (for template type arguments).
• An argument is classified as "definitely a template argument" if it is a name of a C++ template or a Carbon generic (for template template arguments).
• An argument is classified as "definitely a template argument" if it has some explicit marker attached to it -- for example, we could use template x or Cpp.template(x) instead of simply x for such arguments (for trailing explicit non-type template arguments in function calls, which we expect to be very rare).
• All other arguments are classified as "unknown".

We think this will "just work" for almost all cases, with a disambiguation syntax available for the remaining cases.

[chandlerc]

The best option we found given the above constraints is to use the first approach, and to determine which arguments are template arguments based on their types, as follows:

• Each argument is classified as either "definitely a template argument" or "unknown".
• The sequence of template arguments is all arguments up to and including the last "definitely a template argument".
• An argument is classified as "definitely a template argument" if it is of type type (for template type arguments).
• An argument is classified as "definitely a template argument" if it is a name of a C++ template or a Carbon generic (for template template arguments).
• An argument is classified as "definitely a template argument" if it has some explicit marker attached to it -- for example, we could use template x or Cpp.template(x) instead of simply x for such arguments (for trailing explicit non-type template arguments in function calls, which we expect to be very rare).
• All other arguments are classified as "unknown".

While I was nervous about this approach at first, the more I've thought about it the more I both agree with the rationale for picking it over the alternatives and feel like it'll feel reasonably natural in terms of the resulting APIs. I think I'm good with this approach, and given both myself and @zygoloid are happy here, let's call this decided.