There are many useful cases for IUO in Swift - mostly when you have variables that cannot be calculated at the point of calling super.init(), but are guaranteed to be filled during initialization - i.e. during the lifetime of the object, the value is nonnil, but may be nil for a short period of time.
Or @IBOutlets. Making all @IBOutlets optionals would make the code either riddled with ! or shadowed locally re-declared instance members. > On Jun 27, 2016, at 8:12 PM, Jean-Daniel Dupas <[email protected]> wrote: > > Maybe we can prohibit it in Swift function declaration, and allow it only > when importing native code. > > As David, I don’t see any compelling reason to allow such construct in Swift. > >> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution >> <[email protected]> a écrit : >> >> When you import ObjC code that has no nullability annotation, IUO make sense >> since: >> >> - they can be checked against nil >> - typically, most values in APIs are nonnull (looking at Foundation, for >> example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark entire >> regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN) >> >> Importing them as optionals would make it really hard to work with the code >> - whenever you get a value, it's an optional, even in cases where it makes >> no sense and adding ! to unwrap the optional is not a great solution. And >> the other solution is to use guards everywhere. >> >> IMHO the IUO is a nice (temporary) solution for using un-annotated code >> until it is. But the "pressure" should be applied on the ObjC code. >> >>> On Jun 27, 2016, at 10:03 AM, David Rönnqvist <[email protected]> >>> wrote: >>> >>> I don’t know about the chances of getting approved, but I think this is >>> something worth discussing. >>> >>> It might just be my ignorance, but I can’t think of a good reason why a >>> function argument would be force unwrapped. Either it’s non-null and the >>> caller is expected to unwrap it or it’s nullable and the method is expected >>> to handle the nil value. So I’m positive to that part of the proposal. >>> >>> As to what we should do with the generated interfaces of Objective-C code >>> that hasn’t been annotated with nullability, I think that needs input from >>> more people to find the preferred solution. >>> >>> Once that’s been discussed some more, I’d be willing to write up a formal >>> proposal if you don’t feel like it (assuming the discussion leads >>> somewhere). >>> >>> - David >>> >>> >>>> On 27 Jun 2016, at 06:28, Charlie Monroe via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> See https://github.com/apple/swift-evolution/blob/master/process.md - you >>>> would need to make an official proposal and submit it as pull request. But >>>> given the reaction here, it's unlikely to get approved. >>>> >>>> Also, the ObjC code without nullability is getting fairly rare - all >>>> Apple's frameworks are with nullability information (as far as I've >>>> checked) in macOS 10.12, iOS 10. Third party libraries should be updated >>>> to use nullability (and most libraries that are maintained already do). >>>> >>>> >>>>> On Jun 25, 2016, at 5:13 PM, Spromicky via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> So, its proposal is dead, or what we must to do to force it to >>>>> swift-evolution repo on GitHub? >>>>> >>>>>> Hello, everyone! >>>>>> >>>>>> I wanna propose to you to remove force unwrapping in fuction signature >>>>>> for swift code. That no sense in clear swift code. If we wanna use some >>>>>> optional value as function param, that is not optional, we must unwrap >>>>>> it before function call. >>>>>> People who new in swift look at how they old Obj-C code (without >>>>>> nullability modifiers) translate in to swift: >>>>>> >>>>>> Obj-C: >>>>>> - (void)foo:(NSInteger)bar { >>>>>> //... >>>>>> } >>>>>> >>>>>> Swift transaliton: >>>>>> func foo(bar: Int!) { >>>>>> //... >>>>>> } >>>>>> >>>>>> And think that force unwrapping in signature is good practice. And start >>>>>> write functions in clear swift code like this: >>>>>> >>>>>> func newFoo(bar: Int!) { >>>>>> //... >>>>>> } >>>>>> >>>>>> and use it like this: >>>>>> >>>>>> let bar: Int? = 1 >>>>>> newFoo(bar) >>>>>> >>>>>> And it really work, and they does not think that this can crash in case >>>>>> if `bar` will be `nil`. >>>>>> But in clear swift we wanna work with parametrs in function that clearly >>>>>> or optional, or not. >>>>>> >>>>>> func newFoo(bar: Int) { >>>>>> //... >>>>>> } >>>>>> >>>>>> or >>>>>> >>>>>> func newFoo(bar: Int?) { >>>>>> //... >>>>>> } >>>>>> >>>>>> When we write a new function we know what we need in this case and use >>>>>> optional params or not. >>>>>> >>>>>> So my proposal is remove force unwrapping(`!`) from function signatures, >>>>>> cause it have no sense, and that confuse new users. >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
