[swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha]

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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
> david.ronnqvist at gmail.com> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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
> >>>> swift-evolution at swift.org
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/1e6147f5/attachment.html>