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