Does compiler take into account type parameter constraints at all, when resolving overloads? No, because generic constraints are not part of the function signature. You can verify this by adding a Bar overload that is identical except for the generic constraints: interface IBar { } static void Bar<T>(IEnumerable<T> value) where T : IFoo { } … Read more
Why is operator=(int) selected here, instead of “ambiguous” or the other one? {} to int is the identity conversion ([over.ics.list]/9). {} to S is a user-defined conversion ([over.ics.list]/6) (technically, it’s {} to const S&, and goes through [over.ics.list]/8 and [over.ics.ref] first before coming back to [over.ics.list]/6). The first wins. Is there a tidy workaround? A … Read more
The answer is in the C# specification section 7.3 and section 7.5.5.1 I broke down the steps used for choosing the method to invoke. First, the set of all accessible members named N (N=Foo) declared in T (T=class D) and the base types of T (class C) is constructed. Declarations that include an override modifier … Read more
You can create a macro like #define FUNCTORIZE(func) [](auto&&… val) \ noexcept(noexcept(func(std::forward<decltype(val)>(val)…))) -> decltype(auto) \ {return func(std::forward<decltype(val)>(val)…);} which will let you wrap any callable into a closure object. You would use it like auto constexpr predObj = FUNCTORIZE(pred);
It’s obvious to us which function you intend to be chosen, but the compiler has to follow the rules of C++ not use clever leaps of logic (or even not so clever ones, as in simple cases like this!) The relevant constructor of std::function is: template<class F> function(F f); which is a template that accepts … Read more
So to start with, the first expression can only possibly call the first overload. It is not a valid expression for a Func<Task> because there is a code path that returns an invalid value (void instead of Task). () => while(true) is actually a valid method for either signature. (It, along with implementations such as … Read more
Looks like a Clang bug to me. The general rule is that member functions of the same name in different base classes do not overload. For example: struct Foo { void bar(); }; struct Baz { void bar(int); }; struct Quux : Foo, Baz { }; int main() { Quux().bar(); } // error on both … Read more
The unspecialized function templates are also called the underlying base templates. Base templates can be specialized. The overloading rules to see which ones get called in different situations, are pretty simple, at least at a high level: Nontemplate functions are first-class citizens. A plain old nontemplate function that matches the parameter types as well as … Read more
If you have two overloads that differ only in their const-ness, then the compiler resolves the call based on whether *this is const or not. In your example code, test is not const, so the non-const overload is called. If you did this: testType test; const testType &test2 = test; test2->x(); you should see that … Read more
First off, I note that this is a duplicate of: Why is Func<T> ambiguous with Func<IEnumerable<T>>? What’s the exact problem here? Thomas’s guess is essentially correct. Here are the exact details. Let’s go through it a step at a time. We have an invocation: “test”.Select<char, Tuple<char>>(Tuple.Create); Overload resolution must determine the meaning of the call … Read more