I don’t even see the purpose of allowing it in Objective-C code that doesn’t have an annotation. If you can check it against nil, just shadow an optional with a guard…it’s basically the same code and it’s a lot more clear on what’s happening.
On Mon, Jun 27, 2016 at 11:12 AM Jean-Daniel Dupas via swift-evolution < [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
