I think you’re mistaking the scope of the proposal. It’s simply removing IUOs in *function signatures*, not throughout the language.
On Mon, Jun 27, 2016 at 11:31 AM Charlie Monroe via swift-evolution < [email protected]> wrote: > 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 > -- -Saagar Jha
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
