Challenge: adding new method overloads when existing consumers use {} with args
Friedrich W. H. Kossebau
kossebau at kde.org
Thu Jul 28 13:38:38 BST 2022
Am Donnerstag, 28. Juli 2022, 01:50:28 CEST schrieb Thiago Macieira:
> [cross-posting to Qt dev ML - dunno if it'll arrive because I'm subscribed
> with different addresses]
>
> On Wednesday, 27 July 2022 14:54:55 PDT Friedrich W. H. Kossebau wrote:
> > 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?
>
> This case can be considered a Category B source incompatible change as per
> https://quips-qt-io.herokuapp.com/quip-0006.html, because it clearly
> introduces ambiguity.
Thanks for the link, interesting (Sidenote: Not sure I agree that there are
SiCs which are acceptable, I know I got upset a few times by such breakages,
breaking is breaking after all.)
Not sure I understand things correctly: Isn't the addition in our example
rather category A, because it "can be worked around in user code without
introducing [Qt] version checks"? In our example, by using A{}/A() or B{}/B()
when invoking the method?
> But {} is particularly special, so I don't know how we'd deal with it. I
> don't think this has come up for us yet. For one, the mailing list thread
> linked in the QUIP didn't address it.
Not subscribed there these days, will try to read up on the ML archive, but
also happy if you could relay any new info here :)
Cheers
Friedrich
More information about the kde-devel
mailing list