[Pitch] Bridging nil to Objective-C Primitives

[SlaunchaMan (Jeff Kelley)]

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@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

[Rod_Brown]

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@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@gmail.com | @SlaunchaMan | jeffkelley.org
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Charles_Srstka]

What happens if code on the Swift side sets the property’s value to the sentinel?

Charles

···

On Feb 13, 2017, at 9:33 PM, Jeff Kelley via swift-evolution <swift-evolution@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?

[Philippe_Hausler]

The feature in this case I would claim is independent of the adopters. Personally I think this would be a useful feature to allow for better exposition into swift but also more robust objective-c APIs.

Something to consider here is that not all NSUIntegers can be NSNotFound, sometimes the return value is 0. It would be interesting to consider that _Nullable would be parameterized via a constant expression. This is a straw man refinement here (the exact spelling would be something we would have to audit the way it is implemented and likely use macros to compose the right nullability concepts)

Lets take for example this API:

+ (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;

The return value here would be 0 if an error occurs. So the nullability value would be 0.

+ (nullable(0) NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;

But other APIs like you indicated:

- (NSUInteger)indexOfObject:(ObjectType)anObject;

Could be converted to:

- (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;

Which would immediately be an indication to the reader what the “null” value would be represented as. Of course your concept of type aliases might be a decent way to group concepts together but if lets say there was an index type for NSArray; obviously you might want a index return value to be nullable but it would be a bit confusing to take a nullable parameter into certain APIs.

Given a concept of NSArrayIndex as you suggested (that being nullable) would have the problem that

- (ObjectType)objectAtIndex:(NSUInteger)index;

Would either incorrectly indicate it would be nullable or it would have a different type.

There would be other cases where structural types might need a nullable placeholder value, e.g. NSRange with a location of NSNotFound and a length of 0 (however that strictly isn’t correct since it is just the location that indicates null-ness.. but that is probably more of an implementation detail and should probably be corrected imho).

There could also be cases where an API returns either an object of a specific type or NSNull as a placeholder. This would be nice to be able to express as a nullable type especially in generics. For example: `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express `Array<Foo?>` which cannot be expressed currently.

Overall I think this could really reduce some of the overlays for all the frameworks on Mac OS X and iOS, improve the expressivity of Objective-C APIs, offer more accurate bridged representations, and generally give API authors an opportunity to more correctly represent what should be exposed in Swift without needing to write overlays that could easily have poor interaction with things like subclassing or delegation.

As a side note: I am not certain if the parameterization of nullability annotations would even be possible in the current compiler implementations or if it would be easier to use an attribute instead (that would be left to implementation detail).

I would guess that if this feature would be available it would take a combined effort from all API maintainers to annotate their return values and any un-annotated shouldn’t be exposed as a IOU since they have non nil values already. Furthermore the timeframe to do so would probably be independent of the implementation of this type of feature.

Those caveats aside - I think it would be a fantastic tool in the toolbox!

···

On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org> wrote:

On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@icloud.com <mailto:rodney.brown6@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&gt;\.

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@swift.org <mailto:swift-evolution@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@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

Jeff Kelley

SlaunchaMan@gmail.com <mailto:SlaunchaMan@gmail.com> | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[SlaunchaMan (Jeff Kelley)]

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&gt;
.

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 Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@icloud.com> wrote:

On 14 Feb 2017, at 2:33 pm, Jeff Kelley via swift-evolution < > swift-evolution@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@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

[SlaunchaMan (Jeff Kelley)]

Thanks for the feedback! I thought about nullability with type aliases too,
and I think we could avoid some of the issues there with something like
this:

- (ObjectType)objectAtIndex:(nonnull NSArrayIndex)index;

The case where it’s a parameter to a method is easy—I’m not sure where the
_Nonnull would go when there’s no pointer. Perhaps like this:

NSArrayIndex _Nonnull foo = 42;

As far as NSNull as a nullability specifier for arrays and other
Objective-C collections, I think that’s fantastic! Like you said, I see
this as another tool in the toolbox that helps make Objective-C more
self-documenting, both to the developer and the compiler.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

···

On Tue, Feb 14, 2017 at 2:08 PM, Philippe Hausler <phausler@apple.com> wrote:

The feature in this case I would claim is independent of the adopters.
Personally I think this would be a useful feature to allow for better
exposition into swift but also more robust objective-c APIs.

Something to consider here is that not all NSUIntegers can be NSNotFound,
sometimes the return value is 0. It would be interesting to consider that
_Nullable would be parameterized via a constant expression. This is a straw
man refinement here (the exact spelling would be something we would have to
audit the way it is implemented and likely use macros to compose the right
nullability concepts)

Lets take for example this API:

+ (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream
*)stream format:(NSPropertyListFormat)format options:(
NSPropertyListWriteOptions)opt error:(out NSError **)error;

The return value here would be 0 if an error occurs. So the nullability
value would be 0.

+ (nullable(0) NSInteger)writePropertyList:(id)plist
toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format
options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;

But other APIs like you indicated:

- (NSUInteger)indexOfObject:(ObjectType)anObject;

Could be converted to:

- (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;

Which would immediately be an indication to the reader what the “null”
value would be represented as. Of course your concept of type aliases might
be a decent way to group concepts together but if lets say there was an
index type for NSArray; obviously you might want a index return value to be
nullable but it would be a bit confusing to take a nullable parameter into
certain APIs.

Given a concept of NSArrayIndex as you suggested (that being nullable)
would have the problem that

- (ObjectType)objectAtIndex:(NSUInteger)index;

Would either incorrectly indicate it would be nullable or it would have a
different type.

There would be other cases where structural types might need a nullable
placeholder value, e.g. NSRange with a location of NSNotFound and a length
of 0 (however that strictly isn’t correct since it is just the location
that indicates null-ness.. but that is probably more of an implementation
detail and should probably be corrected imho).

There could also be cases where an API returns either an object of a
specific type or NSNull as a placeholder. This would be nice to be able to
express as a nullable type especially in generics. For example:
`NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express
`Array<Foo?>` which cannot be expressed currently.

Overall I think this could really reduce some of the overlays for all the
frameworks on Mac OS X and iOS, improve the expressivity of Objective-C
APIs, offer more accurate bridged representations, and generally give API
authors an opportunity to more correctly represent what should be exposed
in Swift without needing to write overlays that could easily have poor
interaction with things like subclassing or delegation.

As a side note: I am not certain if the parameterization of nullability
annotations would even be possible in the current compiler implementations
or if it would be easier to use an attribute instead (that would be left to
implementation detail).

I would guess that if this feature would be available it would take a
combined effort from all API maintainers to annotate their return values
and any un-annotated shouldn’t be exposed as a IOU since they have non nil
values already. Furthermore the timeframe to do so would probably be
independent of the implementation of this type of feature.

Those caveats aside - I think it would be a fantastic tool in the toolbox!

On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution < > swift-evolution@swift.org> wrote:

On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@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&gt;
.

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@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))index
OfObject:(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@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Douglas_Gregor]

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&gt;\.

For this kind of change to have a real impact, it needs to affect a significant number of frameworks that Swift programmers use. Unless there are automatic heuristics that are *very good*, doing so requires a large amount of manual labor and coordination. So while it is true that Objective-C changes can be in-bounds, from a prioritization/impact perspective, they might not be the right thing to focus on.

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.

In the most general case, one could imagine providing the names of a pair of C functions to the annotation: one answers the question “is this a nil value?” and the other can be called to produce a nil value.

  - Doug

···

On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org> wrote:
On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@icloud.com <mailto:rodney.brown6@icloud.com>> wrote:

[Dietmar_Planitzer]

I would love to see this - and the sooner the better :)

I think that the fact that Swift makes a type-level distinction between optional and non-optional makes it easier to trip yourself up when you work with Cocoa APIs that use pseudo-optionality, compared to when you work with ObjC. In ObjC you are aware 100% of the time that optionality is always represented in some way or another and that you have to expected inconsistency in the representation of optionality. So you keep this in mind and look out for it. But in Swift it’s easy to slide into the assumption that all APIs which return something that’s technically optional do indeed represent this as an optional type rather than some special integer value, float value or singleton object.

Regards,

Dietmar Planitzer

···

On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution <swift-evolution@swift.org> wrote:

The feature in this case I would claim is independent of the adopters. Personally I think this would be a useful feature to allow for better exposition into swift but also more robust objective-c APIs.

Something to consider here is that not all NSUIntegers can be NSNotFound, sometimes the return value is 0. It would be interesting to consider that _Nullable would be parameterized via a constant expression. This is a straw man refinement here (the exact spelling would be something we would have to audit the way it is implemented and likely use macros to compose the right nullability concepts)

Lets take for example this API:

+ (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;

The return value here would be 0 if an error occurs. So the nullability value would be 0.

+ (nullable(0) NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;

But other APIs like you indicated:

- (NSUInteger)indexOfObject:(ObjectType)anObject;

Could be converted to:

- (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;

Which would immediately be an indication to the reader what the “null” value would be represented as. Of course your concept of type aliases might be a decent way to group concepts together but if lets say there was an index type for NSArray; obviously you might want a index return value to be nullable but it would be a bit confusing to take a nullable parameter into certain APIs.

Given a concept of NSArrayIndex as you suggested (that being nullable) would have the problem that

- (ObjectType)objectAtIndex:(NSUInteger)index;

Would either incorrectly indicate it would be nullable or it would have a different type.

There would be other cases where structural types might need a nullable placeholder value, e.g. NSRange with a location of NSNotFound and a length of 0 (however that strictly isn’t correct since it is just the location that indicates null-ness.. but that is probably more of an implementation detail and should probably be corrected imho).

There could also be cases where an API returns either an object of a specific type or NSNull as a placeholder. This would be nice to be able to express as a nullable type especially in generics. For example: `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express `Array<Foo?>` which cannot be expressed currently.

Overall I think this could really reduce some of the overlays for all the frameworks on Mac OS X and iOS, improve the expressivity of Objective-C APIs, offer more accurate bridged representations, and generally give API authors an opportunity to more correctly represent what should be exposed in Swift without needing to write overlays that could easily have poor interaction with things like subclassing or delegation.

As a side note: I am not certain if the parameterization of nullability annotations would even be possible in the current compiler implementations or if it would be easier to use an attribute instead (that would be left to implementation detail).

I would guess that if this feature would be available it would take a combined effort from all API maintainers to annotate their return values and any un-annotated shouldn’t be exposed as a IOU since they have non nil values already. Furthermore the timeframe to do so would probably be independent of the implementation of this type of feature.

Those caveats aside - I think it would be a fantastic tool in the toolbox!

On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org> wrote:

On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@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.

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@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@gmail.com | @SlaunchaMan | jeffkelley.org

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan | jeffkelley.org

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[SlaunchaMan (Jeff Kelley)]

Hi Charles,

If Swift code were to send NSNotFound to a method that took a nullable
NSArrayIndex, under this example, one of two things could happen:

1.) The Swift compiler fails with a fix-it to use nil instead.
2.) The value is passed as-is and Objective-C handles it as usual.

My preference would be for 1, as then the fix-its can help update code to
use the new syntax, but my opinion can definitely be swayed.

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

···

On Fri, Feb 17, 2017 at 3:24 PM, Charles Srstka <cocoadev@charlessoft.com> wrote:

On Feb 13, 2017, at 9:33 PM, Jeff Kelley via swift-evolution < > swift-evolution@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?

What happens if code on the Swift side sets the property’s value to the
sentinel?

Charles

[Pranshu_Goyal]

+1

···

On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution < swift-evolution@swift.org> wrote:

I would love to see this - and the sooner the better :)

I think that the fact that Swift makes a type-level distinction between
optional and non-optional makes it easier to trip yourself up when you work
with Cocoa APIs that use pseudo-optionality, compared to when you work with
ObjC. In ObjC you are aware 100% of the time that optionality is always
represented in some way or another and that you have to expected
inconsistency in the representation of optionality. So you keep this in
mind and look out for it. But in Swift it’s easy to slide into the
assumption that all APIs which return something that’s technically optional
do indeed represent this as an optional type rather than some special
integer value, float value or singleton object.

Regards,

Dietmar Planitzer

> On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution < > swift-evolution@swift.org> wrote:
>
> The feature in this case I would claim is independent of the adopters.
Personally I think this would be a useful feature to allow for better
exposition into swift but also more robust objective-c APIs.
>
> Something to consider here is that not all NSUIntegers can be
NSNotFound, sometimes the return value is 0. It would be interesting to
consider that _Nullable would be parameterized via a constant expression.
This is a straw man refinement here (the exact spelling would be something
we would have to audit the way it is implemented and likely use macros to
compose the right nullability concepts)
>
> Lets take for example this API:
>
> + (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream
*)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt
error:(out NSError **)error;
>
> The return value here would be 0 if an error occurs. So the nullability
value would be 0.
>
> + (nullable(0) NSInteger)writePropertyList:(id)plist
toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format
options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
>
> But other APIs like you indicated:
>
> - (NSUInteger)indexOfObject:(ObjectType)anObject;
>
> Could be converted to:
>
> - (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;
>
> Which would immediately be an indication to the reader what the “null”
value would be represented as. Of course your concept of type aliases might
be a decent way to group concepts together but if lets say there was an
index type for NSArray; obviously you might want a index return value to be
nullable but it would be a bit confusing to take a nullable parameter into
certain APIs.
>
> Given a concept of NSArrayIndex as you suggested (that being nullable)
would have the problem that
>
> - (ObjectType)objectAtIndex:(NSUInteger)index;
>
> Would either incorrectly indicate it would be nullable or it would have
a different type.
>
> There would be other cases where structural types might need a nullable
placeholder value, e.g. NSRange with a location of NSNotFound and a length
of 0 (however that strictly isn’t correct since it is just the location
that indicates null-ness.. but that is probably more of an implementation
detail and should probably be corrected imho).
>
> There could also be cases where an API returns either an object of a
specific type or NSNull as a placeholder. This would be nice to be able to
express as a nullable type especially in generics. For example:
`NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express
`Array<Foo?>` which cannot be expressed currently.
>
> Overall I think this could really reduce some of the overlays for all
the frameworks on Mac OS X and iOS, improve the expressivity of Objective-C
APIs, offer more accurate bridged representations, and generally give API
authors an opportunity to more correctly represent what should be exposed
in Swift without needing to write overlays that could easily have poor
interaction with things like subclassing or delegation.
>
> As a side note: I am not certain if the parameterization of nullability
annotations would even be possible in the current compiler implementations
or if it would be easier to use an attribute instead (that would be left to
implementation detail).
>
> I would guess that if this feature would be available it would take a
combined effort from all API maintainers to annotate their return values
and any un-annotated shouldn’t be exposed as a IOU since they have non nil
values already. Furthermore the timeframe to do so would probably be
independent of the implementation of this type of feature.
>
> Those caveats aside - I think it would be a fantastic tool in the
toolbox!
>
>> On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@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.
>>
>> 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@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@gmail.com | @SlaunchaMan | jeffkelley.org
>>
>>
>>
>> Jeff Kelley
>>
>> SlaunchaMan@gmail.com | @SlaunchaMan | jeffkelley.org
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
*Pranshu Goyal*
*iOS Developer*
*tlkn*

[Alejandro_Martinez]

I would really like to see a nicer way of having Int? Exported to objc. Right now it kind of forces to use NSNumber which may be fine in the objc side but makes swift uglier, unless you want to write that code in a wrapper which doesn't scale really well

···

Sent from my iPad

On 15 Feb 2017, at 09:51, Pranshu Goyal via swift-evolution <swift-evolution@swift.org> wrote:

+1

On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution <swift-evolution@swift.org> wrote:
I would love to see this - and the sooner the better :)

I think that the fact that Swift makes a type-level distinction between optional and non-optional makes it easier to trip yourself up when you work with Cocoa APIs that use pseudo-optionality, compared to when you work with ObjC. In ObjC you are aware 100% of the time that optionality is always represented in some way or another and that you have to expected inconsistency in the representation of optionality. So you keep this in mind and look out for it. But in Swift it’s easy to slide into the assumption that all APIs which return something that’s technically optional do indeed represent this as an optional type rather than some special integer value, float value or singleton object.

Regards,

Dietmar Planitzer

> On Feb 14, 2017, at 11:08, Philippe Hausler via swift-evolution <swift-evolution@swift.org> wrote:
>
> The feature in this case I would claim is independent of the adopters. Personally I think this would be a useful feature to allow for better exposition into swift but also more robust objective-c APIs.
>
> Something to consider here is that not all NSUIntegers can be NSNotFound, sometimes the return value is 0. It would be interesting to consider that _Nullable would be parameterized via a constant expression. This is a straw man refinement here (the exact spelling would be something we would have to audit the way it is implemented and likely use macros to compose the right nullability concepts)
>
> Lets take for example this API:
>
> + (NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
>
> The return value here would be 0 if an error occurs. So the nullability value would be 0.
>
> + (nullable(0) NSInteger)writePropertyList:(id)plist toStream:(NSOutputStream *)stream format:(NSPropertyListFormat)format options:(NSPropertyListWriteOptions)opt error:(out NSError **)error;
>
> But other APIs like you indicated:
>
> - (NSUInteger)indexOfObject:(ObjectType)anObject;
>
> Could be converted to:
>
> - (nullable(NSNotFound) NSUInteger)indexOfObject:(ObjectType)anObject;
>
> Which would immediately be an indication to the reader what the “null” value would be represented as. Of course your concept of type aliases might be a decent way to group concepts together but if lets say there was an index type for NSArray; obviously you might want a index return value to be nullable but it would be a bit confusing to take a nullable parameter into certain APIs.
>
> Given a concept of NSArrayIndex as you suggested (that being nullable) would have the problem that
>
> - (ObjectType)objectAtIndex:(NSUInteger)index;
>
> Would either incorrectly indicate it would be nullable or it would have a different type.
>
> There would be other cases where structural types might need a nullable placeholder value, e.g. NSRange with a location of NSNotFound and a length of 0 (however that strictly isn’t correct since it is just the location that indicates null-ness.. but that is probably more of an implementation detail and should probably be corrected imho).
>
> There could also be cases where an API returns either an object of a specific type or NSNull as a placeholder. This would be nice to be able to express as a nullable type especially in generics. For example: `NSArray<_Nullable(NSNull *) Foo *> *` could be a neat way to express `Array<Foo?>` which cannot be expressed currently.
>
> Overall I think this could really reduce some of the overlays for all the frameworks on Mac OS X and iOS, improve the expressivity of Objective-C APIs, offer more accurate bridged representations, and generally give API authors an opportunity to more correctly represent what should be exposed in Swift without needing to write overlays that could easily have poor interaction with things like subclassing or delegation.
>
> As a side note: I am not certain if the parameterization of nullability annotations would even be possible in the current compiler implementations or if it would be easier to use an attribute instead (that would be left to implementation detail).
>
> I would guess that if this feature would be available it would take a combined effort from all API maintainers to annotate their return values and any un-annotated shouldn’t be exposed as a IOU since they have non nil values already. Furthermore the timeframe to do so would probably be independent of the implementation of this type of feature.
>
> Those caveats aside - I think it would be a fantastic tool in the toolbox!
>
>> On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown <rodney.brown6@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.
>>
>> 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@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@gmail.com | @SlaunchaMan | jeffkelley.org
>>
>>
>>
>> Jeff Kelley
>>
>> SlaunchaMan@gmail.com | @SlaunchaMan | jeffkelley.org
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Pranshu Goyal
iOS Developer
tlkn
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution