rjmccall, 22 days ago

@ctietze If you write obj.method() as NSString in Swift, you should get the result of the call without any bridging

ctietze, 22 days ago

@rjmccall @nicklockwood Oh I didn't know that this would actually avoid bridging.

I'll have to double check in the profiler to make sure

nicklockwood, 22 days ago

@ctietze I think that's an easier problem - NSMutableString doesn't bridge, so if you return that it shouldn't be converted to String by default

ctietze, 22 days ago

@nicklockwood So many of its methods that produce substrings, for example, do bridge though :(

nicklockwood, 22 days ago

@ctietze I'm curious: if you call such a method by saying something like

mutableString.substring(…) as NSString

would Swift actually do a two-way bridging, or is the optimizer smart enough to recognize that the bridging is a no-op in that scenario?

nicklockwood, 22 days ago

@ctietze otherwise, if you control the signature to the method then there are various (slightly ugly) workarounds I can think of, such as returning NSObject and casting it on the Swift side.

ctietze, 22 days ago

@nicklockwood I feared as much!

My original idea was even worse, returning id, but NSObject would be somewhat better

uliwitness, 22 days ago

@ctietze @nicklockwood I wonder what would happen if you declared an ObjC subclass of NSString and returned that. 😈

ctietze, 22 days ago

@uliwitness @nicklockwood 🤯

nicklockwood, 22 days ago

@ctietze another option might be to create an objc protocol that mirrors the NSString API and then conform NSString to it. If you work exclusively with that protocol, Swift wouldn't know how to bridge it

ctietze, 22 days ago

@nicklockwood that's an interesting idea!

I stumbled upon this task in the first place by writing an extension to NSString in ObjC that produced an NSString again, which Swift immediately bridged. Didn't think of a objc-annotated protocol