[swift-evolution] [Pitch] Bridging nil to Objective-C Primitives
rodney.brown6 at icloud.com
Mon Feb 13 22:53:08 CST 2017
I think the biggest problem we're going to face with this one is changes to Objective-C are out of scope for Swift Evolution. Apple tend to be the ones in control of the development of new Objective-C features and compatibility because they control the compiler.
That said, as a request to Apple for this change, I think it's a reasonable idea for Ints, but I'm not sure of its feasibility for other types. Could the API be descriptive enough to cover enough types? (Eg CGRectNull)
> On 14 Feb 2017, at 2:33 pm, Jeff Kelley via swift-evolution <swift-evolution at swift.org> wrote:
> Hi all,
> I don’t have a formal proposal written up yet, but in my continued quest to make better-annotated Objective-C code, I had an idea for bridging nil with primitives. Since in Objective-C we often use constant values to represent invalid values or nil, the most obvious being NSNotFound, could we use that as a shorthand for nil? Something like this for NSArray:
> - (NSUInteger NS_SWIFT_NIL(NSNotFound))indexOfObject:(ObjectType)anObject;
> This is a little verbose, so it could also work with a typedef:
> typedef NSUInteger NS_SWIFT_NIL(NSNotFound) NSArrayIndex;
> - (NSArrayIndex)indexOfObject:(ObjectType)anObject;
> This would change the existing Swift interface to return an Int? instead of an Int. I see this as working both ways—converting these values to nil when returning from Objective-C to Swift, and sending these values instead of nil when Swift calls into Objective-C code.
> Is this worth writing up a proposal for? Is another, better method already in someone’s mind?
> Jeff Kelley
> SlaunchaMan at gmail.com | @SlaunchaMan | jeffkelley.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution