[Interest] Not possible to connect QTcpSocket::error signal the "Qt5-way"?

[André Somers]

Thiago Macieira schreef op 25-11-2013 17:23:
> On segunda-feira, 25 de novembro de 2013 17:00:41, André Somers wrote:
>> Thiago Macieira schreef op 25-11-2013 16:56:
>>> On segunda-feira, 25 de novembro de 2013 13:08:04, André Somers wrote:
>>>> Please note that this goes for *any* method that has an overload. And
>>>> that any method that currently does not have an overload, may still get
>>>> one in the future. If you don't want to run the risk of source
>>>> incompatabilities in the future, I'd always use the explicit signature.
>>> We'll pay more attention to this now that we are taking addresses to
>>> functions.
>> As in: we're not going to introduce any overloads to any public
>> functions anymore? So, a hypothetical function sort() could no longer be
>> overloaded to take an additional parameter like Qt::SortOrder that was
>> overlooked in the first version of the API design?
> Right, we will avoid adding overloads to signals whenever possible. But we
> currently have no automated test for this, so we might regress
> unintentionally.
>
> If someone has some time to add a unit test framework, it would be very
> welcome.
As you can connect to any method (as the slot part of the connection), 
would this policy then not be needed for *all* methods, not just 
signals? Or do I just misunderstand the impact of the issue here?

André