Challenge: adding new method overloads when existing consumers use {} with args

Friedrich W. H. Kossebau kossebau at kde.org
Wed Jul 27 22:54:55 BST 2022


Am Mittwoch, 27. Juli 2022, 13:51:48 CEST schrieb Friedrich W. H. Kossebau:
> Am Montag, 25. Juli 2022, 15:21:43 CEST schrieb Arjen Hiemstra:
> > You could try using SFINAE:
> > 
> > ```
> > struct Test {
> > 
> >         void foo() { }
> >         void foo(const std::vector<int>& t) { }
> >         
> >         template <typename T>
> >         void foo(const T& t, std::enable_if_t<std::is_same<T,
> > 
> > std::map<int,int>>::value, bool> = false)
> > 
> >         {
> >         }
> > 
> > };
> > 
> > Test t;
> > t.foo({});
> > ```
> > 
> > In this case, the second overload will not be considered for `{}` as its
> > type will be deduced as `std::initializer_list` and will not be the same
> > as
> > `std::map<int, int>`.
> 
> Thanks, interesting idea.
> 
> Drawbacks I see:
> * new overload method (and any further ones) will stay special
> * unless implementation is fine to do as part of template,
>   needs another method
> * existing consumer code using {} is not that simple to map by human readers
> as to which overload will be used
> 
> This inspires another idea though (still need to investigate if that works):
> 
> there could be another template overload added which catches any
> `std::initializer_list` arg and delegating to the old method, thus removing
> the ambiguity and also allowing to emit a compiler warning for this usage?

Hm, seems the challenge is that `{}` is not turned directly into a type (and 
how could it be) but stays just a lexical token (correct lingo?) before the 
compiler decides how to resolve this further (beware, parser/lexer are a weak 
spot with me)

So by what I tested the compiler never even tries to interpret these empty 
curly braces into a std::initializer_list, but always happily goes to take it 
as instruction to do value initialization of an instance of the type passed as 
argument with the method call. Unless there are multiple candidates of such 
types (due to method overloads), then it goes to complain about ambiguity (our 
initial problem).

So as of my today experiments seems there is no way to catch the use of {} 
directly?

And has no-one else yet run into this problem? E.g. Qt, anyone seen them 
adding new overloads, what did they do there, if?

Cheers
Friedrich




More information about the kde-devel mailing list