[Development] Binary Compatibility question (KDE)

[Tony Van Eerd]

> -----Original Message-----
> From: development-bounces+tvaneerd=rim.com at qt-project.org
> [mailto:development-bounces+tvaneerd=rim.com at qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Friday, February 28, 2014 11:26 AM
> To: development at qt-project.org
> Subject: Re: [Development] Binary Compatibility question (KDE)
> 
> Em sex 28 fev 2014, às 11:10:41, André Somers escreveu:
> > To me, it doesn't sound reasonable to expect an unqualified &func to
> > stay source compatible. If you want your code to be source compatible
> > with future vesions and you use function pointers, I'd suggest to
> > always use the longer, ugly cast version. I don't think it is
> > unreasonable that in the future overloads are introduced for existing
> > functions, especially for non-slots.
> >
> > BC is IMHO a big enough constraint. Lets not bind our hands even further...
> 
> For most functions, I agree.
> 
> However, we need to be careful about signals. Since they are very, very
> often used in:
> 	connect(obj, &Klass::somethingChanged, ...)
> 
> We need to ensure that we aren't adding overloads to signals.
> 

But in the end, it is only SC break.  So the developer recompiles, and see "ambiguous blah blah blah".  Not too hard to fix.
So I think that can be decided on a case by case basis - is it _really_ important to reuse the same function name, etc. (In most cases, a new name is just easier than trying to imagine all the ways an overload can fail.  But in the odd case, I think overloads should be allowed.  That's how I handle it for the BB10 APIs.)

I think the implicit cast and potentially silently calling a different function, while less likely to happen, is much more serious.

Anyhow, I signed in with OpenID, but still can't edit.  Whatever.  It is not quite important enough to me to keep trying.  But I just wanted to bring it to people's attention in case someone thought it worthwhile.

Tony