Joe Groff

@jckarter @mjtsai @curtclifton What about when Apple writes a framework in Swift? Will it remain swizzlable, probably for use from Obj-C?

@roopeshchander @mjtsai @curtclifton That's a call API review can make when it happens.

@roopeshchander @mjtsai @curtclifton The goal of the resilience defaults is to avoid developers making irrevocable promises they can't keep.

@roopeshchander @mjtsai @curtclifton Being too final or too static is a mistake you can safely fix, but not the other way.

@jckarter @mjtsai @curtclifton I see your point. A default final is a different issue from future Apple frameworks being un-overrideable.

@jckarter @mjtsai @curtclifton Coz, it’s not like Apple can’t add final to all public API even if it’s not a language default. :)

@roopeshchander @jckarter @curtclifton the realities of developing apps are not appreciated/understood. Old system was accidentally good.

@jckarter @jaredsinclair @curtclifton @owensd It does change new frameworks unless you’re going to explicitly mark everything as dynamic.

@mjtsai @jckarter @jaredsinclair @curtclifton @owensd I suspect that’ll happen coz the Swift-written framework should be usable from Obj-C.

@roopeshchander Eventually they’re going to want frameworks that take advantage of Swift features that don’t work with Objective-C.

@mjtsai Agreed. That may be a few decades in the future, but it’s better it’s discussed about now.

@mjtsai OTOH, a Swift framework to be used only from Swift written decades later would most likely use POP => we can override the protocol

@roopeshchander Pretty sure that’s less flexible, though I’m not super familiar with how protocols work under the hood.