What exactly does [[ "ill-formed" ]]] mean in this context?

The phrase, "When checking the validity of a requirement, only the so-called immediate context of the expression is checked," refers to a key concept in C++ called immediate context during the compilation process. It means that during overload resolution or template instantiation, the compiler will check whether an expression can be compiled according to the context in which it is used. This context includes the immediate expressions, types, and template parameters involved in the call.

However, immediate context does not extend to a deep verification of types or instantiations that could happen later if the code were to be executed. This is a critical distinction because C++ allows some flexibility during compilation, especially when it comes to checking whether a given template call can potentially compile or not.

Let's dive deeper into how this idea applies in the context of std::get and overload resolution, with a particular focus on its behavior when provided with a template argument that might be "invalid" but does not result in an immediate error.

C++ Overload Resolution

C++ uses overload resolution to determine which function or template instantiation should be invoked when multiple candidates are available. The rules of overload resolution allow the compiler to choose a suitable function based on the function signature (return type, parameters, and sometimes, template arguments).

The std::get Function and Overload Resolution

The std::get function in C++ is part of the <tuple> library and is used to access elements from a tuple. The function comes in two major forms:

Non-template version that allows you to access elements using an index.

Template version that allows you to access an element by type.

The signature for std::get can look like this:

cpp

Copy code

template <std::size_t I, typename T> T& std::get(T& t); // Non-const version template <typename T, typename Tuple> T& std::get(Tuple& t);
The behavior of std::get with template arguments (especially the overload for accessing tuple elements by type) brings us to the core of the discussion.

Template Instantiations and Invalid Template Arguments

A template instantiation occurs when the compiler generates a function or a class template based on the provided template arguments. In the case of std::get, you can pass a specific index or a type as the template argument.

For instance:

cpp

Copy code

std::tuple<int, double, char> t; auto x = std::get<2>(t); // Access element at index 2
In this case, the template parameter 2 is a valid index, so overload resolution selects the appropriate version of std::get that accesses the third element of the tuple.

However, if you provide an "invalid" type or index (one that cannot match any element in the tuple), the compiler does not immediately check or enforce correctness of the expression—this only happens when the instantiation is needed. In other words, the immediate context of the expression during overload resolution is considered, but the verification of whether the instantiations that are necessary for the function to compile are well-formed, is deferred.

For example, if you try:

cpp

Copy code

auto x = std::get<char>(t); // Invalid, 'char' is not a valid index type.
The call compiles, but it results in the selection of the wrong overload—the overload for std::get<char>—because there is no early rejection of invalid template arguments.

Delayed Validation: How Invalid Template Arguments Are Handled

The key here is that C++ does not immediately reject invalid template arguments during overload resolution. In this case, C++ allows the overload for std::get<char> to be selected, assuming that char is a valid type for tuple indexing. This results in what might be perceived as a "quirk" in the way C++ overload resolution works. However, it's important to note that while the overload resolution succeeds in selecting an incorrect template, the instantiation itself will fail when the code tries to access an element of the tuple based on the invalid template argument.

The Role of cppreference and Function Specification

The documentation for std::get (available on cppreference) specifies that the call to std::get will be ill-formed if the template argument is invalid. This is a late-stage check, meaning that the invalid template argument is not rejected outright during overload resolution but only once the function is fully instantiated.

The key line in cppreference about the ill-formed state is:

"The call shall be ill-formed if the template argument is invalid."

This indicates that while overload resolution can select an incorrect function template based on the immediate context (such as std::get<char>), the template instantiation will fail when evaluated, because the tuple does not contain a type char at the specified index.

FAQ

1. Why is the immediate context important during overload resolution?

The immediate context ensures that the compiler only checks the most relevant aspects of the expression when resolving overloads. The compiler checks the types and arguments directly involved in the expression but does not require a deeper analysis of the instantiations that will occur later. This approach allows for more flexible and efficient compile-time behavior, especially in complex templated code.

2. Why does overload resolution succeed even if the template argument is invalid?

Overload resolution works by considering only the types in the immediate context. If a function template exists that matches the argument types (even if those arguments are not valid for later use), the compiler will choose that template. However, the actual instantiation will fail later if the arguments don't make sense (i.e., when the code is fully evaluated or instantiated).

3. What happens when I pass an invalid template argument to std::get?

If you pass an invalid argument (such as an incorrect index or type) to std::get, overload resolution may select a corresponding overload. However, when the code is fully evaluated, you will get a compilation error because the template argument does not match any valid element in the tuple.

For example:

cpp

Copy code

std::tuple<int, double, char> t; auto x = std::get<char>(t); // Will fail at instantiation, as `char` is not a valid index type.

4. What exactly does "ill-formed" mean in this context?

"Ill-formed" means that the code, once fully instantiated, is not valid according to the C++ language rules. In the case of std::get, this occurs when the provided template argument cannot correspond to a valid element in the tuple. This error will only surface when the function is instantiated.

5. Does this behavior apply to other template functions in C++?

Yes, this behavior of considering only the immediate context during overload resolution applies more broadly in C++. Many template functions or function templates may seem valid during overload resolution but fail when instantiating with invalid or mismatched arguments. This phenomenon is not unique to std::get but is part of C++'s general overload resolution and template instantiation mechanisms.

6. Can this issue be avoided by using constraints or SFINAE?

Yes, constraints such as std::enable_if or C++20's concepts can be used to enforce stricter checks on template arguments, ensuring that only valid types or values are passed to the function. This would allow you to reject incorrect arguments at the time of overload resolution, avoiding the delayed ill-formed error.

For example, you could use:

cpp

Copy code

template <typename T> std::enable_if_t<std::is_integral_v<T>> foo(T t) { ... }

7. Is there a way to preemptively reject invalid template arguments in std::get?

In some cases, concepts or static_assert statements might be used to check the validity of template arguments before the function is called. For instance, you could define a concept to ensure that the template argument is a valid type for indexing a tuple, rejecting the call at compile time if the argument does not satisfy the concept.

8. Does this issue affect performance?

The issue itself—where an invalid template argument is selected during overload resolution but only fails during instantiation—does not affect performance directly. However, failing to catch errors earlier in the compilation process can lead to confusion and longer compile times as the compiler tries to instantiate and evaluate the code.

9. Are there any best practices to avoid similar issues?

To avoid similar issues:

Use constraints (such as SFINAE, enable_if, or concepts) to ensure that only valid template arguments are passed.

Always use explicit, clear template arguments and avoid relying on compiler-generated error messages for template instantiation errors.

10. Could this behavior lead to bugs in large codebases?

Yes, in larger codebases, relying on overload resolution to "choose the right overload" could potentially lead to subtle bugs. These bugs may arise when incorrect template arguments are passed to functions like std::get, only for the error to be discovered later during instantiation. Therefore, careful validation of template arguments (e.g., with static assertions or concepts) is recommended.

Conclusion

In conclusion, the behavior where overload resolution succeeds even with an invalid template argument, but fails at a later stage, illustrates a key aspect of C++'s template system. The immediate context is used during overload resolution to select candidate functions, but the final check of validity occurs during instantiation. While this provides flexibility, it also means that certain types of errors are deferred until later in the compilation process.