Comment by Russ Bishop (JIRA)

@lattner Making the change as suggested broke some tests and I wonder if this will break user code too? (Referencing the member functions loses the magic conversion between the pointer types.)

I can fix the tests or I can add these as overloads - any opinion on which is preferred?

I think that fixing the tests is the right path. @belkadan do you have an opinion on this?

@gribozavr may also have a strong opinion here.

I'm mildly in favor of overloads to not break existing clients, and to not depend on the compiler's conversions, but I'll defer to Dmitri.

Comment by Russ Bishop (JIRA)

@gribozavr Any strong opinions?

Could you add more details, which tests were broken?

Comment by Russ Bishop (JIRA)

@gribozavr It's the `checkPtr` calls in `1_stdlib/UnsafePointer.swift.gyb` because it is passing a member function to a closure so the compiler magic conversion doesn't work. Changing the tests would be trivial.

My question is more philosophical - break user code by changing the existing signatures or add these as overloads?

I just got done running unit tests by implementing this with overloads (as per the original evolution proposal) and compiled foundation; everything worked as expected, nothing broken. Since this should also avoid breaking user code I would lean toward using overloads.

In this case, I think we would choose to break user code. The usecase in the test seems to be a corner case.

Comment by Russ Bishop (JIRA)

#2775