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
