Maybe we can prohibit it in Swift function declaration, and allow it only when 
importing native code.

As David, I don’t see any compelling reason to allow such construct in Swift.

> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution 
> <[email protected]> a écrit :
> 
> When you import ObjC code that has no nullability annotation, IUO make sense 
> since:
> 
> - they can be checked against nil
> - typically, most values in APIs are nonnull (looking at Foundation, for 
> example, which is why Apple has the NS_ASSUME_NONNULL_BEGIN to mark entire 
> regions as nonnull, yet there is no NS_ASSUME_NULL_BEGIN)
> 
> Importing them as optionals would make it really hard to work with the code - 
> whenever you get a value, it's an optional, even in cases where it makes no 
> sense and adding ! to unwrap the optional is not a great solution. And the 
> other solution is to use guards everywhere.
> 
> IMHO the IUO is a nice (temporary) solution for using un-annotated code until 
> it is. But the "pressure" should be applied on the ObjC code.
> 
>> On Jun 27, 2016, at 10:03 AM, David Rönnqvist <[email protected]> 
>> wrote:
>> 
>> I don’t know about the chances of getting approved, but I think this is 
>> something worth discussing. 
>> 
>> It might just be my ignorance, but I can’t think of a good reason why a 
>> function argument would be force unwrapped. Either it’s non-null and the 
>> caller is expected to unwrap it or it’s nullable and the method is expected 
>> to handle the nil value. So I’m positive to that part of the proposal.
>> 
>> As to what we should do with the generated interfaces of Objective-C code 
>> that hasn’t been annotated with nullability, I think that needs input from 
>> more people to find the preferred solution. 
>> 
>> Once that’s been discussed some more, I’d be willing to write up a formal 
>> proposal if you don’t feel like it (assuming the discussion leads somewhere).
>> 
>> - David
>> 
>> 
>>> On 27 Jun 2016, at 06:28, Charlie Monroe via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> See https://github.com/apple/swift-evolution/blob/master/process.md - you 
>>> would need to make an official proposal and submit it as pull request. But 
>>> given the reaction here, it's unlikely to get approved.
>>> 
>>> Also, the ObjC code without nullability is getting fairly rare - all 
>>> Apple's frameworks are with nullability information (as far as I've 
>>> checked) in macOS 10.12, iOS 10. Third party libraries should be updated to 
>>> use nullability (and most libraries that are maintained already do).
>>> 
>>> 
>>>> On Jun 25, 2016, at 5:13 PM, Spromicky via swift-evolution 
>>>> <[email protected]> wrote:
>>>> 
>>>> So, its proposal is dead, or what we must to do to force it to 
>>>> swift-evolution repo on GitHub?
>>>> 
>>>>> Hello, everyone!
>>>>> 
>>>>> I wanna propose to you to remove force unwrapping in fuction signature 
>>>>> for swift code. That no sense in clear swift code. If we wanna use some 
>>>>> optional value as function param, that is not optional, we must unwrap it 
>>>>> before function call.
>>>>> People who new in swift look at how they old Obj-C code (without 
>>>>> nullability modifiers) translate in to swift:
>>>>> 
>>>>> Obj-C:
>>>>> - (void)foo:(NSInteger)bar {
>>>>> //...
>>>>> }
>>>>> 
>>>>> Swift transaliton:
>>>>> func foo(bar: Int!) {
>>>>> //...
>>>>> }
>>>>> 
>>>>> And think that force unwrapping in signature is good practice. And start 
>>>>> write functions in clear swift code like this:
>>>>> 
>>>>> func newFoo(bar: Int!) {
>>>>> //...
>>>>> }
>>>>> 
>>>>> and use it like this:
>>>>> 
>>>>> let bar: Int? = 1
>>>>> newFoo(bar)
>>>>> 
>>>>> And it really work, and they does not think that this can crash in case 
>>>>> if `bar` will be `nil`.
>>>>> But in clear swift we wanna work with parametrs in function that clearly 
>>>>> or optional, or not.
>>>>> 
>>>>> func newFoo(bar: Int) {
>>>>> //...
>>>>> }
>>>>> 
>>>>> or
>>>>> 
>>>>> func newFoo(bar: Int?) {
>>>>> //...
>>>>> }
>>>>> 
>>>>> When we write a new function we know what we need in this case and use 
>>>>> optional params or not.
>>>>> 
>>>>> So my proposal is remove force unwrapping(`!`) from function signatures, 
>>>>> cause it have no sense, and that confuse new users.
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to