https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398
--- Comment #1 from mauro russo <ing.russomauro at gmail dot com> ---
sorry, let me re-style the main() function with related comments, to adapt this
80-columns views.
int main(){
func1(std::set<int>{}); // - gcc behaves as clang about the need to resolve
// lambda types before deciding for the
constraint
// satisfaction.
// - MVSC rejects second overload and selects the
// first one, that is, it considers constrain
// failed due to unfair "it->first" code
// in the lambda expression.
func1(std::map<int,int>{}); // all compilers correctly select second
// overload.
// This time, no reverse problem about "*it",
// and then concept C fails for set iterators.
func1b(std::set<int>{}); // - gcc wrongly considers both overloads as
// eligible, ignoring that "it->first" does not
// work for second overload, likely as
// side-effect of the fact that Cb concept
// resolves as true.
// - clang consistently behaves as for func1.
// - MVSC rejects instead second overload, exactly
as for func1.
//func1b(std::map<int,int>{}); // all compilers correctly consider
ambiguous
// overloads.
func2(std::set<int>{}); // all compilers selects first overload (i.e., gcc
// and clang behaves differently about lambda type
// resolution)
func2(std::map<int,int>{}); // all compilers select second overload,
// as for func1.
}
