[Proposal] Remove force unwrapping in function signature

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
carryover from Java. They show up in method signatures from
non-nullable-annotated Java, but you can't define a new method that takes
e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see
areas where IUOs are clearly useful (ViewControllers for instance) but
defining new functions that take implicitly unwrapped optionals makes no
sense. If you need to pass a IUO at the call site, you can define the
function taking a non-optional value and pass the IUO to that. There is no
use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in Kotlin
where there is also inconsistency in the same vein. I see it simply as a
compromise that achieves the goal of keeping a useful feature but
discouraging its overuse by forbidding its use in places where its use
could confuse and snowball down the line into teaching developers worse
code quality.

···

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote:

Ok, I see - though I find myself using occasionally IUOs in Swift as well
- e.g. when you can't use the default values because they depend on self,
etc.

Eliminating it just from method signatures IMHO brings an incosistency
into the language. Why would you eliminate it only from method signatures -
this proposal mentioned importing ObjC API in the beginning - why not then
mark those properties all as optional as well? IUOs are scheduled to be
removed completely once the language reaches a point where it can handle
most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying,
NSSecureCoding, NSFastEnumeration {

    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

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@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@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@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@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@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@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@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Alright, I’ve written it up a proposal; you can find it here
<https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. This
is my first proposal (and anyways I’ve been told that I can be unclear), so
if you guys see anything that should be changed feel free to let me know.
Here it is inline:
Remove implicitly unwrapped optionals as function parameters

   - Proposal: SE-NNNN
   <NNNN-remove-implicitly-unwrapped-function-parameters.md>
   - Author: Swift Developer <https://github.com/swiftdev&gt;
   - Status: *Awaiting review*
   - Review manager: TBD

Introduction

Swift, in contrast with Objective-C, makes a distinction between values
that may be nil and values that can never be nil through its use of
Optionals. Due to the fact that Objective-C does not make this distinction,
Objective-C functions that do not use the Nullability
<Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported
with parameters of the implicitly unwrapped optional type. Unfortunately,
this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
    //…
}

Due to the confusion this may cause, we would like to propose the *removal
of implicitly unwrapped optionals as function parameters*. Discussion on
this topic may be found here
<http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.
Motivation

Implicitly unwrapped optionals are currently allowed in function
declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

possiblyNil is an Int?; thus, this example will not compile due to
triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

While this version compiles, it crashes due to the force unwrapping of a nil
value. Unfortunately, the compiler "hides" this fact by making it seem like
it's acceptable to pass in nil–it doesn't make the forced unwrapping
*explicit*.
Proposed solution

The safest solution, in this case, is to prevent the use of implicitly
unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

or

func triple(forceUnwrapping aNumber: Int?) -> Int {
    return aNumber * 3
}

the compiler will complain, reminding users that they should probably
attempt to safely unwrap the optional before using it.
Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in
function signatures for both Swift code as well as imported Objective-C
code. As non-annotated Objective-C functions are currently imported as
implicitly unwrapped, they will be converted to optionals as a preliminary
step. Non-audited frameworks can be audited in the future so that they can
be tagged with _Nonnull if necessary.
Impact on existing code

This is a proposal is a source breaking change, but it should be easily
mitigated using a migrator. Existing functions with implicitly unwrapped
optionals can be changed to optional; users can easily shadow variables
with a guard or change their function to non-optional.
Alternatives considered Importing Objective-C functions as-is, but
disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability
annotations, but creates a sort of disconnect between Objective-C and Swift
in that it prevents Swift developers from writing functions with implicitly
unwrapped optionals.
Doing nothing

Obviously, this has the benefit of keeping the current behavior and not
requiring a migrator. However, I believe that the unsafe behavior that this
encourages is not worth keeping.

···

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko <dennis.s.lysenko@gmail.com> wrote:

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
carryover from Java. They show up in method signatures from
non-nullable-annotated Java, but you can't define a new method that takes
e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see
areas where IUOs are clearly useful (ViewControllers for instance) but
defining new functions that take implicitly unwrapped optionals makes no
sense. If you need to pass a IUO at the call site, you can define the
function taking a non-optional value and pass the IUO to that. There is no
use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in Kotlin
where there is also inconsistency in the same vein. I see it simply as a
compromise that achieves the goal of keeping a useful feature but
discouraging its overuse by forbidding its use in places where its use
could confuse and snowball down the line into teaching developers worse
code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote:

Ok, I see - though I find myself using occasionally IUOs in Swift as well
- e.g. when you can't use the default values because they depend on self,
etc.

Eliminating it just from method signatures IMHO brings an incosistency
into the language. Why would you eliminate it only from method signatures -
this proposal mentioned importing ObjC API in the beginning - why not then
mark those properties all as optional as well? IUOs are scheduled to be
removed completely once the language reaches a point where it can handle
most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying,
NSSecureCoding, NSFastEnumeration {

    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

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@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@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@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@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@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@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@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--

-Saagar Jha

Wait, it looks like String(byRepeatingString: aString, count: 3) only works
on characters and was removed, replace it with aString + aString + aString.

···

On Fri, Jun 10, 2016 at 7:38 PM Saagar Jha <saagarjha28@gmail.com> wrote:

Yes, that’s what I meant. Basically, I see stuff like this:

func tripleForceUnwrapping(aString: String!) -> String {
    return String(byRepeatingString: aString, count: 3)
}

and later users get a crash with this:

let possiblyNilString = someFunctionThatRetunsAnOptional()
tripleForceUnwrapping(possiblyNilString)

even though it compiles fine.

func tripleWithoutUnwrapping(aString: String?) -> String {
    return String(byRepeatingString: aString, count: 3)
}

let possiblyNilString = someFunctionThatRetunsAnOptional()
tripleWithoutUnwrapping(possiblyNilString)

meanwhile, doesn’t compile and forces the user to think “huh, it’s not
compiling because there’s an Optional” and hopefully add a check

On Fri, Jun 10, 2016 at 7:18 PM Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote:

> On Jun 10, 2016, at 7:43 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> on Thu Jun 09 2016, Saagar Jha <swift-evolution@swift.org> wrote:
>
>> Yes, that’s exactly my point. Force unwrapping optionals adds
>> confusion for new users; all too often I see newcomers ending up with
>> the assumption that the force unwrapping takes care of the check for
>> them.
>
> ...but, it *does*.

I took Saagar to mean “the assumption that force unwrapping takes care of
doing the right thing for them so they don’t ever have to think about nil
at all.” Which is indeed quite common in beginner Swift code.

Sadly, there is no compile-time check for mindfulness.

Cheers, P

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

--
-Saagar Jha

Alright, I’ve written it up a proposal; you can find it here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. This is my first proposal (and anyways I’ve been told that I can be unclear), so if you guys see anything that should be changed feel free to let me know. Here it is inline:

Hi Saagar,

If I understand your proposal correctly, you are suggesting that we remove T! and just force people to use T? or T. This is a commonly rejected proposal (though not on the list yet) that frequently comes up. The problem with your proposal is that you don’t provide any solutions to the problems that T! is currently solving: that of two-phase initialization and importing of APIs that have not been nullability audited. It isn’t pragmatic to handle these cases as T?

-Chris

···

On Jun 27, 2016, at 4:42 PM, Saagar Jha via swift-evolution <swift-evolution@swift.org> wrote:

Remove implicitly unwrapped optionals as function parameters

Proposal: SE-NNNN <x-msg://38/NNNN-remove-implicitly-unwrapped-function-parameters.md>
Author: Swift Developer <https://github.com/swiftdev&gt;
Status: Awaiting review
Review manager: TBD
Introduction

Swift, in contrast with Objective-C, makes a distinction between values that may be nil and values that can never be nil through its use of Optionals. Due to the fact that Objective-C does not make this distinction, Objective-C functions that do not use the Nullability <Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported with parameters of the implicitly unwrapped optional type. Unfortunately, this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
    //…
}
Due to the confusion this may cause, we would like to propose the removal of implicitly unwrapped optionals as function parameters. Discussion on this topic may be found here <http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.

Motivation

Implicitly unwrapped optionals are currently allowed in function declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)
possiblyNil is an Int?; thus, this example will not compile due to triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)
While this version compiles, it crashes due to the force unwrapping of a nil value. Unfortunately, the compiler "hides" this fact by making it seem like it's acceptable to pass in nil–it doesn't make the forced unwrapping explicit.

Proposed solution

The safest solution, in this case, is to prevent the use of implicitly unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}
or

func triple(forceUnwrapping aNumber: Int?) -> Int {
    return aNumber * 3
}
the compiler will complain, reminding users that they should probably attempt to safely unwrap the optional before using it.

Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in function signatures for both Swift code as well as imported Objective-C code. As non-annotated Objective-C functions are currently imported as implicitly unwrapped, they will be converted to optionals as a preliminary step. Non-audited frameworks can be audited in the future so that they can be tagged with _Nonnull if necessary.

Impact on existing code

This is a proposal is a source breaking change, but it should be easily mitigated using a migrator. Existing functions with implicitly unwrapped optionals can be changed to optional; users can easily shadow variables with a guard or change their function to non-optional.

Alternatives considered

Importing Objective-C functions as-is, but disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability annotations, but creates a sort of disconnect between Objective-C and Swift in that it prevents Swift developers from writing functions with implicitly unwrapped optionals.

Doing nothing

Obviously, this has the benefit of keeping the current behavior and not requiring a migrator. However, I believe that the unsafe behavior that this encourages is not worth keeping.

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:
+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a carryover from Java. They show up in method signatures from non-nullable-annotated Java, but you can't define a new method that takes e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see areas where IUOs are clearly useful (ViewControllers for instance) but defining new functions that take implicitly unwrapped optionals makes no sense. If you need to pass a IUO at the call site, you can define the function taking a non-optional value and pass the IUO to that. There is no use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in Kotlin where there is also inconsistency in the same vein. I see it simply as a compromise that achieves the goal of keeping a useful feature but discouraging its overuse by forbidding its use in places where its use could confuse and snowball down the line into teaching developers worse code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Ok, I see - though I find myself using occasionally IUOs in Swift as well - e.g. when you can't use the default values because they depend on self, etc.

Eliminating it just from method signatures IMHO brings an incosistency into the language. Why would you eliminate it only from method signatures - this proposal mentioned importing ObjC API in the beginning - why not then mark those properties all as optional as well? IUOs are scheduled to be removed completely once the language reaches a point where it can handle most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration {
    
    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

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@swift.org <mailto:swift-evolution@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@xenonium.com <mailto:mailing@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@swift.org <mailto:swift-evolution@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@gmail.com <mailto:david.ronnqvist@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yes please, current Swift 3 Snapshot translated a lot of C functions from not optionals to optionals just because let and var works correctly on UnsafeMutablePointer’s.

This is confusing and ugly:

public func freeaddrinfo(_: UnsafeMutablePointer<addrinfo>!)
public func gai_strerror(_: Int32) -> UnsafePointer<Int8>!
public func getaddrinfo(_: UnsafePointer<Int8>!, _: UnsafePointer<Int8>!, _: UnsafePointer<addrinfo>!, _: UnsafeMutablePointer<UnsafeMutablePointer<addrinfo>?>!) -> Int32
public func gethostbyaddr(_: UnsafePointer<Swift.Void>!, _: socklen_t, _: Int32) -> UnsafeMutablePointer<hostent>!
public func gethostbyname(_: UnsafePointer<Int8>!) -> UnsafeMutablePointer<hostent>!
public func gethostent() -> UnsafeMutablePointer<hostent>!
public func getnameinfo(_: UnsafePointer<sockaddr>!, _: socklen_t, _: UnsafeMutablePointer<Int8>!, _: socklen_t, _: UnsafeMutablePointer<Int8>!, _: socklen_t, _: Int32) -> Int32
public func getnetbyaddr(_: UInt32, _: Int32) -> UnsafeMutablePointer<netent>!
public func getnetbyname(_: UnsafePointer<Int8>!) -> UnsafeMutablePointer<netent>!
public func getnetent() -> UnsafeMutablePointer<netent>!
public func getprotobyname(_: UnsafePointer<Int8>!) -> UnsafeMutablePointer<protoent>!
public func getprotobynumber(_: Int32) -> UnsafeMutablePointer<protoent>!
public func getprotoent() -> UnsafeMutablePointer<protoent>!
public func getservbyname(_: UnsafePointer<Int8>!, _: UnsafePointer<Int8>!) -> UnsafeMutablePointer<servent>!
public func getservbyport(_: Int32, _: UnsafePointer<Int8>!) -> UnsafeMutablePointer<servent>!
public func getservent() -> UnsafeMutablePointer<servent>!
Look at this mess!

···

--
Adrian Zubarev
Sent with Airmail

Hi Saagar,

If I understand your proposal correctly, you are suggesting that we remove T! and just force people to use T? or T. This is a commonly rejected proposal (though not on the list yet) that frequently comes up. The problem with your proposal is that you don’t provide any solutions to the problems that T! is currently solving: that of two-phase initialization and importing of APIs that have not been nullability audited. It isn’t pragmatic to handle these cases as T?

-Chris

Chris,

I believe he only is speaking to removing the ability to use IUOs as function parameters, not as properties (for 2-phase init) or return values (for unaudited API). The question would be what the impact would be of unaudited API being imported as accepting an explicit optional rather than IUO.

-DW

···

Remove implicitly unwrapped optionals as function parameters

Proposal: SE-NNNN <x-msg://38/NNNN-remove-implicitly-unwrapped-function-parameters.md>
Author: Swift Developer <https://github.com/swiftdev&gt;
Status: Awaiting review
Review manager: TBD
Introduction

Swift, in contrast with Objective-C, makes a distinction between values that may be nil and values that can never be nil through its use of Optionals. Due to the fact that Objective-C does not make this distinction, Objective-C functions that do not use the Nullability <Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported with parameters of the implicitly unwrapped optional type. Unfortunately, this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
    //…
}
Due to the confusion this may cause, we would like to propose the removal of implicitly unwrapped optionals as function parameters. Discussion on this topic may be found here <http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.

Motivation

Implicitly unwrapped optionals are currently allowed in function declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)
possiblyNil is an Int?; thus, this example will not compile due to triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)
While this version compiles, it crashes due to the force unwrapping of a nil value. Unfortunately, the compiler "hides" this fact by making it seem like it's acceptable to pass in nil–it doesn't make the forced unwrapping explicit.

Proposed solution

The safest solution, in this case, is to prevent the use of implicitly unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}
or

func triple(forceUnwrapping aNumber: Int?) -> Int {
    return aNumber * 3
}
the compiler will complain, reminding users that they should probably attempt to safely unwrap the optional before using it.

Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in function signatures for both Swift code as well as imported Objective-C code. As non-annotated Objective-C functions are currently imported as implicitly unwrapped, they will be converted to optionals as a preliminary step. Non-audited frameworks can be audited in the future so that they can be tagged with _Nonnull if necessary.

Impact on existing code

This is a proposal is a source breaking change, but it should be easily mitigated using a migrator. Existing functions with implicitly unwrapped optionals can be changed to optional; users can easily shadow variables with a guard or change their function to non-optional.

Alternatives considered

Importing Objective-C functions as-is, but disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability annotations, but creates a sort of disconnect between Objective-C and Swift in that it prevents Swift developers from writing functions with implicitly unwrapped optionals.

Doing nothing

Obviously, this has the benefit of keeping the current behavior and not requiring a migrator. However, I believe that the unsafe behavior that this encourages is not worth keeping.

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:
+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a carryover from Java. They show up in method signatures from non-nullable-annotated Java, but you can't define a new method that takes e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see areas where IUOs are clearly useful (ViewControllers for instance) but defining new functions that take implicitly unwrapped optionals makes no sense. If you need to pass a IUO at the call site, you can define the function taking a non-optional value and pass the IUO to that. There is no use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in Kotlin where there is also inconsistency in the same vein. I see it simply as a compromise that achieves the goal of keeping a useful feature but discouraging its overuse by forbidding its use in places where its use could confuse and snowball down the line into teaching developers worse code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Ok, I see - though I find myself using occasionally IUOs in Swift as well - e.g. when you can't use the default values because they depend on self, etc.

Eliminating it just from method signatures IMHO brings an incosistency into the language. Why would you eliminate it only from method signatures - this proposal mentioned importing ObjC API in the beginning - why not then mark those properties all as optional as well? IUOs are scheduled to be removed completely once the language reaches a point where it can handle most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration {
    
    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

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@swift.org <mailto:swift-evolution@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@xenonium.com <mailto:mailing@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@swift.org <mailto:swift-evolution@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@gmail.com <mailto:david.ronnqvist@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Hi Chris! It proposal only about function parameters, not about all IUO. In some cases IUO is great solution. For example class properties. If you write something like this

var bar: Int!

It is clearly understandable that you wanna say “Yes, in some moment after init `bar` will be `nil`, but it will be initialised before use, I guarantee this.” Its great and useful. In this code:

func foo(bar: Int!) {
    //...
}

what we wanna say? “You can pass `nil`, but i do not wanna unwrap this” or “I guarantee that bar will be unwrapped”? I think parameters T! make no sense for function signature. You clearly understand what you wanna see as parameter in function - optional or non-optional.

And what about legacy Obj-C code.
We can understand why we use this when import legacy Obj-C code without nullability annotations. In Obj-C we can have valid methods, that get `nil` as parameter. For example:

- (void)foo:(UINavigationController *)navController
{
    [navController popViewControllerAnimated:YES];
}

or not:

- (NSMutableArray *)foo:(NSNumber *)bar
{
    NSMutableArray *array = [[NSMutableArray alloc] init];
    [array addObject:bar];
    return array;
}

So before swift about nullability we wrote in documentation. About can this method get `nil` or not.
Let’s think about import this method in swift. If we import legacy methods like this in swift with non-optional parameters by default we disable valid `nil`-pass method like in first example. But if we import by default as optional - we mistakenly say
that second method can get `nil`, and therefore get crash. So we import like IUO params. But behaviour of IUO-code is same as with optional params. By placing `!` in parameter type we just trying to say “Man, parameter can be `nil` (cause in Obj-C it can be `nil`), but method maybe not handle `nil` as parameter. Be careful.” And if we remove `!` in parameter type, I think we can say it by different way.

I hope I explain my point.

···

> On Jun 27, 2016, at 4:42 PM, Saagar Jha via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
>
> Alright, I’ve written it up a proposal; you can find ithere(https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453\). This is my first proposal (and anyways I’ve been told that I can be unclear), so if you guys see anything that should be changed feel free to let me know. Here it is inline:
>
>
>
HiSaagar,

If I understand your proposal correctly, you are suggesting that we remove T! and just force people to use T? or T.This is a commonly rejected proposal (though not on the list yet) that frequently comes up.The problem with your proposal is that you don’t provide any solutions to the problems that T! is currently solving: that of two-phase initialization and importing of APIs that have not been nullability audited.It isn’t pragmatic to handle these cases as T?

-Chris
> Remove implicitly unwrapped optionals as function parameters
> Proposal:SE-NNNN(x-msg://38/NNNN-remove-implicitly-unwrapped-function-parameters.md)
> Author:Swift Developer(https://github.com/swiftdev\)
> Status:Awaiting review
> Review manager: TBD
>
> Introduction
>
> Swift, in contrast with Objective-C, makes a distinction between values that may beniland values that can never benilthrough its use of Optionals. Due to the fact that Objective-C does not make this distinction, Objective-C functions that do not use theNullability(Swift Blog - Apple Developer)annotations are imported with parameters of the implicitly unwrapped optional type. Unfortunately, this allows users to write their own Swift code that looks like this:
>
> func foo(bar: Int!) { //… }
>
> Due to the confusion this may cause, we would like to propose theremoval of implicitly unwrapped optionals as function parameters. Discussion on this topic may be foundhere(http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/\).
>
> Motivation
>
> Implicitly unwrapped optionals are currently allowed in function declarations. Consider the following function:
>
> func triple(forceUnwrapping aNumber: Int) ->Int { return aNumber * 3 } let possiblyNil = Int("foo") triple(forceUnwrapping: possiblyNil)
>
> possiblyNilis anInt?; thus, this example will not compile due totriple(forceUnwrapping:)expecting anInt. It is easy to imagine a Swift beginner writing code that looks like this to "fix" the problem:
>
> func triple(forceUnwrapping aNumber: Int!) ->Int { return aNumber * 3 } let possiblyNil = Int("foo") triple(forceUnwrapping: possiblyNil)
>
> While this version compiles, it crashes due to the force unwrapping of anilvalue. Unfortunately, the compiler "hides" this fact by making it seem like it's acceptable to pass innil–it doesn't make the forced unwrappingexplicit.
>
> Proposed solution
>
> The safest solution, in this case, is to prevent the use of implicitly unrwapped optionals in function signatures. By forcing users to write
>
> func triple(forceUnwrapping aNumber: Int) ->Int { return aNumber * 3 }
>
> or
>
> func triple(forceUnwrapping aNumber: Int?) ->Int { return aNumber * 3 }
>
> the compiler will complain, reminding users that they should probably attempt to safely unwrap the optional before using it.
>
> Detailed design
>
> The proposal will prevent the use of implicitly unwrapped optionals in function signatures for both Swift code as well as imported Objective-C code. As non-annotated Objective-C functions are currently imported as implicitly unwrapped, they will be converted to optionals as a preliminary step. Non-audited frameworks can be audited in the future so that they can be tagged with_Nonnullif necessary.
>
> Impact on existing code
>
> This is a proposal is a source breaking change, but it should be easily mitigated using a migrator. Existing functions with implicitly unwrapped optionals can be changed to optional; users can easily shadow variables with aguardor change their function to non-optional.
>
> Alternatives considered
> Importing Objective-C functions as-is, but disallowing implictly unwrapped optionals in Swift code
>
> This reduces the burden on existing frameworks and adding Nullability annotations, but creates a sort of disconnect between Objective-C and Swift in that it prevents Swift developers from writing functions with implicitly unwrapped optionals.
>
> Doing nothing
>
> Obviously, this has the benefit of keeping the current behavior and not requiring a migrator. However, I believe that the unsafe behavior that this encourages is not worth keeping.
>
>
>
> On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko<dennis.s.lysenko@gmail.com(mailto:dennis.s.lysenko@gmail.com)>wrote:
> > +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a carryover from Java. They show up in method signatures from non-nullable-annotated Java, but you can't define a new method that takes e.g. an Int!.
> >
> > The limited scope of this proposal is ideal in my opinion since we see areas where IUOs are clearly useful (ViewControllers for instance) but defining new functions that take implicitly unwrapped optionals makes no sense. If you need to pass a IUO at the call site, you can define the function taking a non-optional value and pass the IUO to that. There is no use case I can think of for having it in method/function signatures.
> >
> > RE: language inconsistencies, there is no such issue in practice in Kotlin where there is also inconsistency in the same vein. I see it simply as a compromise that achieves the goal of keeping a useful feature but discouraging its overuse by forbidding its use in places where its use could confuse and snowball down the line into teaching developers worse code quality.
> > On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > > Ok, I see - though I find myself using occasionally IUOs in Swift as well - e.g. when you can't use the default values because they depend on self, etc.
> > >
> > > Eliminating it just from method signatures IMHO brings an incosistency into the language. Why would you eliminate it only from method signatures - this proposal mentioned importing ObjC API in the beginning - why not then mark those properties all as optional as well? IUOs are scheduled to be removed completely once the language reaches a point where it can handle most scenarios otherwise...
> > >
> > > Try to imagine some APIs brought to Swift with default being nullable:
> > >
> > > /// Imported from
> > > publicclassNSOrderedSet :NSObject,NSCopying,NSMutableCopying,NSSecureCoding,NSFastEnumeration{
> > >
> > > publicvarcount:Int{ get }
> > > publicfuncobjectAtIndex(idx:Int) ->AnyObject?
> > > publicfuncindexOfObject(object:AnyObject?) ->Int
> > > publicinit()
> > > publicinit(objects:UnsafePointer<AnyObject?>, count cnt:Int)
> > > publicinit?(coder aDecoder:NSCoder?)
> > > }
> > >
> > >
> > > This doesn't make much sense - mostly objectAtIndex(_:).
> > >
> > > > On Jun 27, 2016, at 8:35 PM, Saagar Jha<saagarjha28@gmail.com(mailto:saagarjha28@gmail.com)>wrote:
> > > > I think you’re mistaking the scope of the proposal. It’s simply removing IUOs infunction signatures, not throughout the language.
> > > > On Mon, Jun 27, 2016 at 11:31 AM Charlie Monroe via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@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@xenonium.com(mailto:mailing@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@swift.org(mailto:swift-evolution@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@gmail.com(mailto:david.ronnqvist@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@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > > > > >>>>
> > > > > >>>>Seehttps://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@swift.org(mailto:swift-evolution@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@swift.org(mailto:swift-evolution@swift.org)
> > > > > >>>>>https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > > >>>>
> > > > > >>>>_______________________________________________
> > > > > >>>>swift-evolution mailing list
> > > > > >>>>swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > > > >>>>https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > > >>>
> > > > > >>
> > > > > >>_______________________________________________
> > > > > >>swift-evolution mailing list
> > > > > >>swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > > > >>https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > swift-evolution mailing list
> > > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > --
> > > > -Saagar Jha
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> --
> -Saagar Jha_______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution

Alright, I’ve written it up a proposal; you can find it here
<https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\.
This is my first proposal (and anyways I’ve been told that I can be
unclear), so if you guys see anything that should be changed feel free to
let me know. Here it is inline:

Hi Saagar,

If I understand your proposal correctly, you are suggesting that we remove
T! and just force people to use T? or T. This is a commonly rejected

As I understand, Saagar suggests to disallow T! for function parameters only. And allow only T or T?.

About the API, as I understand, the suggestion is to explicitly use guard:

func someAPIFunc(t: T?) {
     guard let t = t else { fatalError("t==nil was not expected in someAPIFunc") }

     // code of function
     print(t) // `t` is not optional here
}

From one side this adds more boilerplate code for API functions, but from other - such function is very clear about the behavior in case of `nil` sent to such function. I.e. all is explicit and clear. With IUO it is not obvious what will be the behavior if `nil` will be sent to func.
Personally I'm not sure if I'm +1 for this suggestion or -1.. Probably +1 because of more obvious behavior and the fact that we can have more descriptive error in case of `nil` in such function.

···

On 29.06.2016 6:57, Chris Lattner via swift-evolution wrote:

On Jun 27, 2016, at 4:42 PM, Saagar Jha via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

proposal (though not on the list yet) that frequently comes up. The
problem with your proposal is that you don’t provide any solutions to the
problems that T! is currently solving: that of two-phase initialization and
importing of APIs that have not been nullability audited. It isn’t
pragmatic to handle these cases as T?

-Chris

  Remove implicitly unwrapped optionals as function parameters

  * Proposal: SE-NNNN
    <x-msg://38/NNNN-remove-implicitly-unwrapped-function-parameters.md>
  * Author: Swift Developer <https://github.com/swiftdev&gt;
  * Status: *Awaiting review*
  * Review manager: TBD

    Introduction

Swift, in contrast with Objective-C, makes a distinction between values
that may be |nil| and values that can never be |nil| through its use of
Optionals. Due to the fact that Objective-C does not make this
distinction, Objective-C functions that do not use the Nullability
<Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported
with parameters of the implicitly unwrapped optional type. Unfortunately,
this allows users to write their own Swift code that looks like this:

>func foo(bar: Int!) { //… } |

Due to the confusion this may cause, we would like to propose the
*removal of implicitly unwrapped optionals as function parameters*.
Discussion on this topic may be found here
<http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.

    Motivation

Implicitly unwrapped optionals are currently allowed in function
declarations. Consider the following function:

>func triple(forceUnwrapping aNumber: Int) -> Int { return aNumber * 3 }
let possiblyNil = Int("foo") triple(forceUnwrapping: possiblyNil) |

>possiblyNil> is an |Int?|; thus, this example will not compile due to
>triple(forceUnwrapping:)| expecting an |Int|. It is easy to imagine a
Swift beginner writing code that looks like this to "fix" the problem:

>func triple(forceUnwrapping aNumber: Int!) -> Int { return aNumber * 3 }
let possiblyNil = Int("foo") triple(forceUnwrapping: possiblyNil) |

While this version compiles, it crashes due to the force unwrapping of a
>nil> value. Unfortunately, the compiler "hides" this fact by making it
seem like it's acceptable to pass in |nil|–it doesn't make the forced
unwrapping *explicit*.

    Proposed solution

The safest solution, in this case, is to prevent the use of implicitly
unrwapped optionals in function signatures. By forcing users to write

>func triple(forceUnwrapping aNumber: Int) -> Int { return aNumber * 3 } |

or

>func triple(forceUnwrapping aNumber: Int?) -> Int { return aNumber * 3 } |

the compiler will complain, reminding users that they should probably
attempt to safely unwrap the optional before using it.

    Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in
function signatures for both Swift code as well as imported Objective-C
code. As non-annotated Objective-C functions are currently imported as
implicitly unwrapped, they will be converted to optionals as a
preliminary step. Non-audited frameworks can be audited in the future so
that they can be tagged with |_Nonnull| if necessary.

    Impact on existing code

This is a proposal is a source breaking change, but it should be easily
mitigated using a migrator. Existing functions with implicitly unwrapped
optionals can be changed to optional; users can easily shadow variables
with a |guard| or change their function to non-optional.

    Alternatives considered

      Importing Objective-C functions as-is, but disallowing implictly
      unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability
annotations, but creates a sort of disconnect between Objective-C and
Swift in that it prevents Swift developers from writing functions with
implicitly unwrapped optionals.

      Doing nothing

Obviously, this has the benefit of keeping the current behavior and not
requiring a migrator. However, I believe that the unsafe behavior that
this encourages is not worth keeping.

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko >> <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:

    +1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly
    a carryover from Java. They show up in method signatures from
    non-nullable-annotated Java, but you can't define a new method that
    takes e.g. an Int!.

    The limited scope of this proposal is ideal in my opinion since we
    see areas where IUOs are clearly useful (ViewControllers for
    instance) but defining new functions that take implicitly unwrapped
    optionals makes no sense. If you need to pass a IUO at the call site,
    you can define the function taking a non-optional value and pass the
    IUO to that. There is no use case I can think of for having it in
    method/function signatures.

    RE: language inconsistencies, there is no such issue in practice in
    Kotlin where there is also inconsistency in the same vein. I see it
    simply as a compromise that achieves the goal of keeping a useful
    feature but discouraging its overuse by forbidding its use in places
    where its use could confuse and snowball down the line into teaching
    developers worse code quality.

    On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

        Ok, I see - though I find myself using occasionally IUOs in Swift
        as well - e.g. when you can't use the default values because they
        depend on self, etc.

        Eliminating it just from method signatures IMHO brings an
        incosistency into the language. Why would you eliminate it only
        from method signatures - this proposal mentioned importing ObjC
        API in the beginning - why not then mark those properties all as
        optional as well? IUOs are scheduled to be removed completely
        once the language reaches a point where it can handle most
        scenarios otherwise...

        Try to imagine some APIs brought to Swift with default being
        nullable:

        /// Imported from
        publicclassNSOrderedSet : NSObject, NSCopying, NSMutableCopying,
        NSSecureCoding, NSFastEnumeration{

            publicvarcount: Int{ get }
            publicfuncobjectAtIndex(idx: Int) -> AnyObject?
            publicfuncindexOfObject(object: AnyObject?) -> Int
            publicinit()
            publicinit(objects: UnsafePointer<AnyObject?>, count cnt: Int)
            publicinit?(coder aDecoder: NSCoder?)
        }

        This doesn't make much sense - mostly objectAtIndex(_:).

        On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com >>> <mailto:saagarjha28@gmail.com>> wrote:

        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@swift.org >>> <mailto:swift-evolution@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@xenonium.com <mailto:mailing@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@swift.org >>> <mailto:swift-evolution@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@gmail.com >>> <mailto:david.ronnqvist@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@swift.org >>> <mailto:swift-evolution@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@swift.org >>> <mailto:swift-evolution@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@swift.org
            <mailto:swift-evolution@swift.org>
            >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
            >>>>
            >>>> _______________________________________________
            >>>> swift-evolution mailing list
            >>>> swift-evolution@swift.org
            <mailto:swift-evolution@swift.org>
            >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
            >>>
            >>
            >> _______________________________________________
            >> swift-evolution mailing list
            >> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
            >> https://lists.swift.org/mailman/listinfo/swift-evolution
            >

            _______________________________________________
            swift-evolution mailing list
            swift-evolution@swift.org <mailto:swift-evolution@swift.org>
            https://lists.swift.org/mailman/listinfo/swift-evolution

        --
        -Saagar Jha

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Adrian Zubarev wrote:

Yes please, current Swift 3 Snapshot translated a lot of
C functions from not optionals to optionals just because
let and var works correctly on UnsafeMutablePointer’s.

I think this is due to:

* "SE-0055: Making pointer nullability explicit"
  <https://github.com/apple/swift/pull/1878&gt;

* IUOs for code without "nullability annotations"
  <Nullability and Objective-C - Swift Blog - Apple Developer;

-- Ben

Yep, that’s what I meant. I should probably go back and re-write the
proposal if it’s not clear.

BTW, when does the window for proposals close? Is this in the scope for
Swift 3?

···

On Tue, Jun 28, 2016 at 9:54 PM David Waite <david@alkaline-solutions.com> wrote:

Hi Saagar,

If I understand your proposal correctly, you are suggesting that we remove
T! and just force people to use T? or T. This is a commonly rejected
proposal (though not on the list yet) that frequently comes up. The
problem with your proposal is that you don’t provide any solutions to the
problems that T! is currently solving: that of two-phase initialization and
importing of APIs that have not been nullability audited. It isn’t
pragmatic to handle these cases as T?

-Chris

Chris,

I believe he only is speaking to removing the ability to use IUOs as
function parameters, not as properties (for 2-phase init) or return values
(for unaudited API). The question would be what the impact would be of
unaudited API being imported as accepting an explicit optional rather than
IUO.

-DW

Remove implicitly unwrapped optionals as function parameters

   - Proposal: SE-NNNN
   - Author: Swift Developer <https://github.com/swiftdev&gt;
   - Status: *Awaiting review*
   - Review manager: TBD

Introduction

Swift, in contrast with Objective-C, makes a distinction between values
that may be nil and values that can never be nil through its use of
Optionals. Due to the fact that Objective-C does not make this distinction,
Objective-C functions that do not use the Nullability
<Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported
with parameters of the implicitly unwrapped optional type. Unfortunately,
this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
    //…
}

Due to the confusion this may cause, we would like to propose the *removal
of implicitly unwrapped optionals as function parameters*. Discussion on
this topic may be found here
<http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.
Motivation

Implicitly unwrapped optionals are currently allowed in function
declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

possiblyNil is an Int?; thus, this example will not compile due to
triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

While this version compiles, it crashes due to the force unwrapping of a
nil value. Unfortunately, the compiler "hides" this fact by making it
seem like it's acceptable to pass in nil–it doesn't make the forced
unwrapping *explicit*.
Proposed solution

The safest solution, in this case, is to prevent the use of implicitly
unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

or

func triple(forceUnwrapping aNumber: Int?) -> Int {
    return aNumber * 3
}

the compiler will complain, reminding users that they should probably
attempt to safely unwrap the optional before using it.
Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in
function signatures for both Swift code as well as imported Objective-C
code. As non-annotated Objective-C functions are currently imported as
implicitly unwrapped, they will be converted to optionals as a preliminary
step. Non-audited frameworks can be audited in the future so that they can
be tagged with _Nonnull if necessary.
Impact on existing code

This is a proposal is a source breaking change, but it should be easily
mitigated using a migrator. Existing functions with implicitly unwrapped
optionals can be changed to optional; users can easily shadow variables
with a guard or change their function to non-optional.
Alternatives consideredImporting Objective-C functions as-is, but
disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability
annotations, but creates a sort of disconnect between Objective-C and Swift
in that it prevents Swift developers from writing functions with implicitly
unwrapped optionals.
Doing nothing

Obviously, this has the benefit of keeping the current behavior and not
requiring a migrator. However, I believe that the unsafe behavior that this
encourages is not worth keeping.

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko <dennis.s.lysenko@gmail.com> > wrote:

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
carryover from Java. They show up in method signatures from
non-nullable-annotated Java, but you can't define a new method that takes
e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see
areas where IUOs are clearly useful (ViewControllers for instance) but
defining new functions that take implicitly unwrapped optionals makes no
sense. If you need to pass a IUO at the call site, you can define the
function taking a non-optional value and pass the IUO to that. There is no
use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in
Kotlin where there is also inconsistency in the same vein. I see it simply
as a compromise that achieves the goal of keeping a useful feature but
discouraging its overuse by forbidding its use in places where its use
could confuse and snowball down the line into teaching developers worse
code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution < >> swift-evolution@swift.org> wrote:

Ok, I see - though I find myself using occasionally IUOs in Swift as
well - e.g. when you can't use the default values because they depend on
self, etc.

Eliminating it just from method signatures IMHO brings an incosistency
into the language. Why would you eliminate it only from method signatures -
this proposal mentioned importing ObjC API in the beginning - why not then
mark those properties all as optional as well? IUOs are scheduled to be
removed completely once the language reaches a point where it can handle
most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying,
NSSecureCoding, NSFastEnumeration {

    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

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@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@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@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@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@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@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@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--

-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--

-Saagar Jha

Yep, that’s what I meant. I should probably go back and re-write the proposal if it’s not clear.

BTW, when does the window for proposals close? Is this in the scope for Swift 3?

Ok, I missed that.

I still dont’ understand why it is a good thing though. IUO arguments exist not just for calls, but for declarations. It is pretty common to implement an override of a method that has IUO’s. Likewise, disallowing them for parameters, but allowing them for properties and return values just seems inconsistent and asymmetrical.

IUO is an important part of the Swift model. I think that the changes we’ve already made go a long way to making it behave predictably and limit their scope. Syntactically limiting where they can occur just makes Swift irregular, for no apparent (to me) gain.

-Chris

···

On Jun 28, 2016, at 10:04 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

On Tue, Jun 28, 2016 at 9:54 PM David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:

Hi Saagar,

If I understand your proposal correctly, you are suggesting that we remove T! and just force people to use T? or T. This is a commonly rejected proposal (though not on the list yet) that frequently comes up. The problem with your proposal is that you don’t provide any solutions to the problems that T! is currently solving: that of two-phase initialization and importing of APIs that have not been nullability audited. It isn’t pragmatic to handle these cases as T?

-Chris

Chris,

I believe he only is speaking to removing the ability to use IUOs as function parameters, not as properties (for 2-phase init) or return values (for unaudited API). The question would be what the impact would be of unaudited API being imported as accepting an explicit optional rather than IUO.

-DW

Remove implicitly unwrapped optionals as function parameters

Proposal: SE-NNNN <>
Author: Swift Developer <https://github.com/swiftdev&gt;
Status: Awaiting review
Review manager: TBD
Introduction

Swift, in contrast with Objective-C, makes a distinction between values that may be nil and values that can never be nil through its use of Optionals. Due to the fact that Objective-C does not make this distinction, Objective-C functions that do not use the Nullability <Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported with parameters of the implicitly unwrapped optional type. Unfortunately, this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
    //…
}
Due to the confusion this may cause, we would like to propose the removal of implicitly unwrapped optionals as function parameters. Discussion on this topic may be found here <http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.

Motivation

Implicitly unwrapped optionals are currently allowed in function declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)
possiblyNil is an Int?; thus, this example will not compile due to triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)
While this version compiles, it crashes due to the force unwrapping of a nil value. Unfortunately, the compiler "hides" this fact by making it seem like it's acceptable to pass in nil–it doesn't make the forced unwrapping explicit.

Proposed solution

The safest solution, in this case, is to prevent the use of implicitly unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}
or

func triple(forceUnwrapping aNumber: Int?) -> Int {
    return aNumber * 3
}
the compiler will complain, reminding users that they should probably attempt to safely unwrap the optional before using it.

Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in function signatures for both Swift code as well as imported Objective-C code. As non-annotated Objective-C functions are currently imported as implicitly unwrapped, they will be converted to optionals as a preliminary step. Non-audited frameworks can be audited in the future so that they can be tagged with _Nonnull if necessary.

Impact on existing code

This is a proposal is a source breaking change, but it should be easily mitigated using a migrator. Existing functions with implicitly unwrapped optionals can be changed to optional; users can easily shadow variables with a guard or change their function to non-optional.

Alternatives considered

Importing Objective-C functions as-is, but disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability annotations, but creates a sort of disconnect between Objective-C and Swift in that it prevents Swift developers from writing functions with implicitly unwrapped optionals.

Doing nothing

Obviously, this has the benefit of keeping the current behavior and not requiring a migrator. However, I believe that the unsafe behavior that this encourages is not worth keeping.

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko <dennis.s.lysenko@gmail.com <mailto:dennis.s.lysenko@gmail.com>> wrote:
+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a carryover from Java. They show up in method signatures from non-nullable-annotated Java, but you can't define a new method that takes e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see areas where IUOs are clearly useful (ViewControllers for instance) but defining new functions that take implicitly unwrapped optionals makes no sense. If you need to pass a IUO at the call site, you can define the function taking a non-optional value and pass the IUO to that. There is no use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in Kotlin where there is also inconsistency in the same vein. I see it simply as a compromise that achieves the goal of keeping a useful feature but discouraging its overuse by forbidding its use in places where its use could confuse and snowball down the line into teaching developers worse code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Ok, I see - though I find myself using occasionally IUOs in Swift as well - e.g. when you can't use the default values because they depend on self, etc.

Eliminating it just from method signatures IMHO brings an incosistency into the language. Why would you eliminate it only from method signatures - this proposal mentioned importing ObjC API in the beginning - why not then mark those properties all as optional as well? IUOs are scheduled to be removed completely once the language reaches a point where it can handle most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration {
    
    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

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@swift.org <mailto:swift-evolution@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@xenonium.com <mailto:mailing@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@swift.org <mailto:swift-evolution@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@gmail.com <mailto:david.ronnqvist@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

Now that I think of it, IUOs for function returns have a similar problem.
When I see an IUO property, I consider it a sort of “contract”–it’s
basically saying something like “I can’t set this to a valid value right
now, but by the time you use it I promise that it’s non nil”. That’s why
IUOs make sense as properties and @IBOutlets, since they’re nil during
initialization, but when you need them they have a value (assuming you’ve
hooked up your outlets properly). The problem with using IUOs in functions
as parameters or return types is that this sort of promise doesn’t hold up;
the function could act on the value immediately and saying something like
“it might be nil right now, but I’ll change it” doesn’t work since you have
no control of what the function does with it. Similarly with a return
value, there is no way to guarantee the setting of an IUO before it’s used.
If there’s any doubt that the value is possibly nil, a regular Optional
should be used.

A lot of the time this just turns out for an excuse for programmers to
shoehorn an Optional without a check; save for imported APIs I haven’t seen
someone use an IUO as a function parameter if they’re not trying to get
around compiler complaints.

···

On Wed, Jun 29, 2016 at 5:45 PM Chris Lattner <clattner@apple.com> wrote:

On Jun 28, 2016, at 10:04 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Yep, that’s what I meant. I should probably go back and re-write the
proposal if it’s not clear.

BTW, when does the window for proposals close? Is this in the scope for
Swift 3?

Ok, I missed that.

I still dont’ understand why it is a good thing though. IUO arguments
exist not just for calls, but for declarations. It is pretty common to
implement an override of a method that has IUO’s. Likewise, disallowing
them for parameters, but allowing them for properties and return values
just seems inconsistent and asymmetrical.

IUO is an important part of the Swift model. I think that the changes
we’ve already made go a long way to making it behave predictably and limit
their scope. Syntactically limiting where they can occur just makes Swift
irregular, for no apparent (to me) gain.

-Chris

On Tue, Jun 28, 2016 at 9:54 PM David Waite <david@alkaline-solutions.com> > wrote:

Hi Saagar,

If I understand your proposal correctly, you are suggesting that we
remove T! and just force people to use T? or T. This is a commonly
rejected proposal (though not on the list yet) that frequently comes up.
The problem with your proposal is that you don’t provide any solutions to
the problems that T! is currently solving: that of two-phase initialization
and importing of APIs that have not been nullability audited. It isn’t
pragmatic to handle these cases as T?

-Chris

Chris,

I believe he only is speaking to removing the ability to use IUOs as
function parameters, not as properties (for 2-phase init) or return values
(for unaudited API). The question would be what the impact would be of
unaudited API being imported as accepting an explicit optional rather than
IUO.

-DW

Remove implicitly unwrapped optionals as function parameters

   - Proposal: SE-NNNN
   - Author: Swift Developer <https://github.com/swiftdev&gt;
   - Status: *Awaiting review*
   - Review manager: TBD

Introduction

Swift, in contrast with Objective-C, makes a distinction between values
that may be nil and values that can never be nil through its use of
Optionals. Due to the fact that Objective-C does not make this distinction,
Objective-C functions that do not use the Nullability
<Nullability and Objective-C - Swift Blog - Apple Developer; annotations are imported
with parameters of the implicitly unwrapped optional type. Unfortunately,
this allows users to write their own Swift code that looks like this:

func foo(bar: Int!) {
    //…
}

Due to the confusion this may cause, we would like to propose the *removal
of implicitly unwrapped optionals as function parameters*. Discussion on
this topic may be found here
<http://article.gmane.org/gmane.comp.lang.swift.evolution/21730/&gt;\.
Motivation

Implicitly unwrapped optionals are currently allowed in function
declarations. Consider the following function:

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

possiblyNil is an Int?; thus, this example will not compile due to
triple(forceUnwrapping:) expecting an Int. It is easy to imagine a Swift
beginner writing code that looks like this to "fix" the problem:

func triple(forceUnwrapping aNumber: Int!) -> Int {
    return aNumber * 3
}

let possiblyNil = Int("foo")
triple(forceUnwrapping: possiblyNil)

While this version compiles, it crashes due to the force unwrapping of a
nil value. Unfortunately, the compiler "hides" this fact by making it
seem like it's acceptable to pass in nil–it doesn't make the forced
unwrapping *explicit*.
Proposed solution

The safest solution, in this case, is to prevent the use of implicitly
unrwapped optionals in function signatures. By forcing users to write

func triple(forceUnwrapping aNumber: Int) -> Int {
    return aNumber * 3
}

or

func triple(forceUnwrapping aNumber: Int?) -> Int {
    return aNumber * 3
}

the compiler will complain, reminding users that they should probably
attempt to safely unwrap the optional before using it.
Detailed design

The proposal will prevent the use of implicitly unwrapped optionals in
function signatures for both Swift code as well as imported Objective-C
code. As non-annotated Objective-C functions are currently imported as
implicitly unwrapped, they will be converted to optionals as a preliminary
step. Non-audited frameworks can be audited in the future so that they can
be tagged with _Nonnull if necessary.
Impact on existing code

This is a proposal is a source breaking change, but it should be easily
mitigated using a migrator. Existing functions with implicitly unwrapped
optionals can be changed to optional; users can easily shadow variables
with a guard or change their function to non-optional.
Alternatives consideredImporting Objective-C functions as-is, but
disallowing implictly unwrapped optionals in Swift code

This reduces the burden on existing frameworks and adding Nullability
annotations, but creates a sort of disconnect between Objective-C and Swift
in that it prevents Swift developers from writing functions with implicitly
unwrapped optionals.
Doing nothing

Obviously, this has the benefit of keeping the current behavior and not
requiring a migrator. However, I believe that the unsafe behavior that this
encourages is not worth keeping.

On Mon, Jun 27, 2016 at 1:35 PM Dennis Lysenko < >> dennis.s.lysenko@gmail.com> wrote:

+1. This is sort of how Kotlin does it. In Kotlin, IUOs are strictly a
carryover from Java. They show up in method signatures from
non-nullable-annotated Java, but you can't define a new method that takes
e.g. an Int!.

The limited scope of this proposal is ideal in my opinion since we see
areas where IUOs are clearly useful (ViewControllers for instance) but
defining new functions that take implicitly unwrapped optionals makes no
sense. If you need to pass a IUO at the call site, you can define the
function taking a non-optional value and pass the IUO to that. There is no
use case I can think of for having it in method/function signatures.

RE: language inconsistencies, there is no such issue in practice in
Kotlin where there is also inconsistency in the same vein. I see it simply
as a compromise that achieves the goal of keeping a useful feature but
discouraging its overuse by forbidding its use in places where its use
could confuse and snowball down the line into teaching developers worse
code quality.

On Mon, Jun 27, 2016 at 12:04 PM Charlie Monroe via swift-evolution < >>> swift-evolution@swift.org> wrote:

Ok, I see - though I find myself using occasionally IUOs in Swift as
well - e.g. when you can't use the default values because they depend on
self, etc.

Eliminating it just from method signatures IMHO brings an incosistency
into the language. Why would you eliminate it only from method signatures -
this proposal mentioned importing ObjC API in the beginning - why not then
mark those properties all as optional as well? IUOs are scheduled to be
removed completely once the language reaches a point where it can handle
most scenarios otherwise...

Try to imagine some APIs brought to Swift with default being nullable:

/// Imported from
public class NSOrderedSet : NSObject, NSCopying, NSMutableCopying,
NSSecureCoding, NSFastEnumeration {

    public var count: Int { get }
    public func objectAtIndex(idx: Int) -> AnyObject?
    public func indexOfObject(object: AnyObject?) -> Int
    public init()
    public init(objects: UnsafePointer<AnyObject?>, count cnt: Int)
    public init?(coder aDecoder: NSCoder?)
}

This doesn't make much sense - mostly objectAtIndex(_:).

On Jun 27, 2016, at 8:35 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

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@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@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@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@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@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@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@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--

-Saagar Jha
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--

-Saagar Jha

--

-Saagar Jha

You might say that an IUO is sort of an IOU?

-W

···

On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution <swift-evolution@swift.org> wrote:

When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”

Gave me a chuckle, but yeah, basically.

···

On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley < wjs@delicious-monster.com> wrote:

On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution < > swift-evolution@swift.org> wrote:

When I see an IUO property, I consider it a sort of “contract”–it’s
basically saying something like “I can’t set this to a valid value right
now, but by the time you use it I promise that it’s non nil”

You might say that an IUO is sort of an IOU?

-W

--
-Saagar Jha

I have updated the proposal here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. Since this is a potentially a source breaking change, I’d like this to be considered for Swift 3; unless anyone has any issues with it, I’m going to push this to swift-evolution.

Saagar Jha

···

On Jul 5, 2016, at 13:30, Saagar Jha <saagarjha28@gmail.com> wrote:

Gave me a chuckle, but yeah, basically.

On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley <wjs@delicious-monster.com <mailto:wjs@delicious-monster.com>> wrote:
On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”

You might say that an IUO is sort of an IOU?

-W
--
-Saagar Jha

I have updated the proposal here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. Since this is a potentially a source breaking change, I’d like this to be considered for Swift 3; unless anyone has any issues with it, I’m going to push this to swift-evolution.

Some comments:
- The syntax proposed would be *completely* unlike anything in Swift, and is semantically changing things unrelated to the type.
- This proposal doesn’t work, and overly punishes IUOs.

I recommend that we do not discuss this proposal, as it would not be a good use of community time. Beyond the unworkability of this specific proposal, in my personal opinion, there is nothing wrong with the T! syntax. Making it significantly more verbose would be a very *bad* thing for the intended use cases.

-Chris

···

On Jul 19, 2016, at 3:46 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Saagar Jha

On Jul 5, 2016, at 13:30, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

Gave me a chuckle, but yeah, basically.

On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley <wjs@delicious-monster.com <mailto:wjs@delicious-monster.com>> wrote:
On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”

You might say that an IUO is sort of an IOU?

-W
--
-Saagar Jha

Hi Saagar,

I’m sorry for the response above, I apparently misunderstood your early example to read it as putting the force unwrapping concept into the “forceUnwrapping” parameter label.

I now see that your idea is to remove force unwrapping entirely for parameters. I am very concerned about this and think it would not be accepted into Swift. It makes the language less consistent (why can you do it on a property, but not a parameter) and eliminates important use cases for T!: overriding an non-nullability audited method.

-Chris

···

On Jul 20, 2016, at 12:52 PM, Chris Lattner <clattner@apple.com> wrote:

On Jul 19, 2016, at 3:46 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

I have updated the proposal here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. Since this is a potentially a source breaking change, I’d like this to be considered for Swift 3; unless anyone has any issues with it, I’m going to push this to swift-evolution.

Some comments:
- The syntax proposed would be *completely* unlike anything in Swift, and is semantically changing things unrelated to the type.
- This proposal doesn’t work, and overly punishes IUOs.

I recommend that we do not discuss this proposal, as it would not be a good use of community time. Beyond the unworkability of this specific proposal, in my personal opinion, there is nothing wrong with the T! syntax. Making it significantly more verbose would be a very *bad* thing for the intended use cases.

(Comments inline)
Saagar Jha

I have updated the proposal here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. Since this is a potentially a source breaking change, I’d like this to be considered for Swift 3; unless anyone has any issues with it, I’m going to push this to swift-evolution.

I know you don’t really want to discuss it, but since I don’t quite get what you mean, I was wondering if you could clarify a bit more why this proposal is inappropriate.

Some comments:
- The syntax proposed would be *completely* unlike anything in Swift, and is semantically changing things unrelated to the type.

There is no new syntax proposed; it is simply a restriction on the current syntax of using IUOs in functions, which I feel encourages unsafe behavior. The “syntax change” is no more than changing something like this:

func triple(forceUnwrapping aNumber: Int!) -> Int? {
    guard aNumber != nil else {
        return nil
    }
    return aNumber * 3
}
to

func triple(withoutUnwrapping aNumber: Int?) -> Int? {
    guard let aNumber = aNumber else { // simply transform the check
        return nil
    }
    return aNumber * 3
}

There’s not much of a difference, except that at the it makes it easier to see that nil is properly handled at the call site.

- This proposal doesn’t work, and overly punishes IUOs.

My goal is not to “punish” IUOs. I recognize that IUOs have valid uses, for example during initialization–and I want to leave this alone since this is the purpose of IUOs. My issue is with IUOs being “used as Optionals” in that they are allowed to have a nil value and checked for it (or not, with disastrous results). I’ve yet to see a function with an IUO parameter that couldn’t be rewritten to be clearer and more safe with a plain Optional parameter. Is there anything I’ve overlooked?

I recommend that we do not discuss this proposal, as it would not be a good use of community time. Beyond the unworkability of this specific proposal, in my personal opinion, there is nothing wrong with the T! syntax. Making it significantly more verbose would be a very *bad* thing for the intended use cases.

As before, this proposal is not an attack on IUOs and the T! syntax, it’s against their misuse as function parameters and return values. A significant increase in verbosity is obviously undesirable, but I don’t see how this proposal will cause an increase in length.

···

On Jul 20, 2016, at 16:47, Saagar Jha <saagarjha28@gmail.com> wrote:
On Wed, Jul 20, 2016 at 12:52 PM Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Jul 19, 2016, at 3:46 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

-Chris

Saagar Jha

On Jul 5, 2016, at 13:30, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

Gave me a chuckle, but yeah, basically.

On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley <wjs@delicious-monster.com <mailto:wjs@delicious-monster.com>> wrote:
On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”

You might say that an IUO is sort of an IOU?

-W
--
-Saagar Jha

Are “forceUnwrapping” and “withoutUnwrapping” special keywords here or are they just there to try to explain what you’re doing? Because I was very confused by them.

-Wil

Sorry for the last email…I didn’t see your response.

I realize that disallowing IUOs in parameters (but not as properties) is inconsistent, but IUOs for properties make sense: they must be set during initialization, but sometimes this isn’t possible. IUOs make it possible to use the property just as any other non-Optional one, provided the property is set before it is used (see the proposal). This kind of guarantee doesn’t work for function parameters and return values.

As for IUOs for non-audited methods; why can’t they just all use Optional parameters? It should have the same behavior as before, since you can pass in both an Optional as well as a non-Optional even today.

Saagar Jha

···

On Jul 20, 2016, at 17:13, Chris Lattner <clattner@apple.com> wrote:

On Jul 20, 2016, at 12:52 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jul 19, 2016, at 3:46 PM, Saagar Jha <saagarjha28@gmail.com <mailto:saagarjha28@gmail.com>> wrote:

I have updated the proposal here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453&gt;\. Since this is a potentially a source breaking change, I’d like this to be considered for Swift 3; unless anyone has any issues with it, I’m going to push this to swift-evolution.

Some comments:
- The syntax proposed would be *completely* unlike anything in Swift, and is semantically changing things unrelated to the type.
- This proposal doesn’t work, and overly punishes IUOs.

I recommend that we do not discuss this proposal, as it would not be a good use of community time. Beyond the unworkability of this specific proposal, in my personal opinion, there is nothing wrong with the T! syntax. Making it significantly more verbose would be a very *bad* thing for the intended use cases.

Hi Saagar,

I’m sorry for the response above, I apparently misunderstood your early example to read it as putting the force unwrapping concept into the “forceUnwrapping” parameter label.

I now see that your idea is to remove force unwrapping entirely for parameters. I am very concerned about this and think it would not be accepted into Swift. It makes the language less consistent (why can you do it on a property, but not a parameter) and eliminates important use cases for T!: overriding an non-nullability audited method.

-Chris