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

[Saagar Jha]

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 <
swift-evolution at swift.org> 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 <mailing at xenonium.com>
> 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/c9f7ceec/attachment.html>