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

[Pranshu Goyal]

+1

On 15 February 2017 at 15:12, Dietmar Planitzer via swift-evolution <
swift-evolution at 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 at 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 at swift.org> wrote:
> >>
> >> 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.
> >>
> >> 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 | jeffkelley.org
> >>
> >>
> >>
> >> Jeff Kelley
> >>
> >> SlaunchaMan at gmail.com | @SlaunchaMan | jeffkelley.org
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170215/37751229/attachment.html>