[swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

Jeff Kelley slaunchaman at gmail.com
Tue Feb 14 12:41:50 CST 2017


On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6 at icloud.com>
wrote:

> 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.
>

I don’t think that Objective-C changes are out of bounds when Swift is
involved—see my past, accepted proposal at SE-0033
<https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md>
.


> 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)
>

It’s an open-and-shut case for any standard primitive, but structs like
CGRect are where it starts to get tricky. I see that CGRect conforms to
Equatable when it’s imported into Swift; perhaps that could be enough for
this to work? If the translation to and from nil happens in the Swift side,
I can see Equatable as a reasonable requirement for the type.



> 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 <https://twitter.com/SlaunchaMan> |
> jeffkelley.org
>
>


Jeff Kelley

SlaunchaMan at gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> |
jeffkelley.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170214/bfd0a182/attachment.html>


More information about the swift-evolution mailing list