+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.bro...@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 > >>> > >>> slauncha...@gmail.com | @SlaunchaMan | jeffkelley.org > >> > >> > >> > >> Jeff Kelley > >> > >> slauncha...@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