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