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.
But doesn't Int! In parameter type means the function is awaiting an unwrapped value so the user should ensure that it data parameter is available, valid, and unwrapped?
···
--
J. Charles
Le 8 juin 2016 à 13:30, Spromicky via swift-evolution <swift-evolution@swift.org> a écrit :
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
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.
+1 I agree. Unwrapping in the functional signature is confusing for the
user; many don’t realize that it puts the burden of checking on them.
Non-optional function parameters make this explicit by preventing passing
in Optional types, forcing the user to check, which they should be doing
anyway.
···
On Wed, Jun 8, 2016 at 12:22 PM J. Charles M. N. via swift-evolution < swift-evolution@swift.org> wrote:
This confused me at the beginning.
But doesn't Int! In parameter type means the function is awaiting an
unwrapped value so the user should ensure that it data parameter is
available, valid, and unwrapped?
--
J. Charles
> Le 8 juin 2016 à 13:30, Spromicky via swift-evolution < > swift-evolution@swift.org> a écrit :
>
> 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
Yep, but no one stop you if you pass optional value. And in runtime it crash in case if it really will be `nil`. But from other side non-optional params make the same, and does not let you pass an optional value, and show error on compile time. This make your code more safety.
Now force unwrapped params in function used only if you use old Obj-C code without nullability modifiers, so no sense, i think, for clear swift code.
···
This confused me at the beginning.
But doesn't Int! In parameter type means the function is awaiting an unwrapped value so the user should ensure that it data parameter is available, valid, and unwrapped?
--
J. Charles
> Le 8 juin 2016 à 13:30, Spromicky via swift-evolution<swift-evolution@swift.org>a écrit :
>
> 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
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.
I agree we could disallow explicitly declaring implicitly unwrapped
function parameters, but this will be needed for the clang importer since
there will still be many C and ObjC APIs not tagged for nullability.
···
On Wed, Jun 8, 2016 at 2:46 PM Saagar Jha via swift-evolution < swift-evolution@swift.org> wrote:
+1 I agree. Unwrapping in the functional signature is confusing for the
user; many don’t realize that it puts the burden of checking on them.
Non-optional function parameters make this explicit by preventing passing
in Optional types, forcing the user to check, which they should be doing
anyway.
On Wed, Jun 8, 2016 at 12:22 PM J. Charles M. N. via swift-evolution < > swift-evolution@swift.org> wrote:
This confused me at the beginning.
But doesn't Int! In parameter type means the function is awaiting an
unwrapped value so the user should ensure that it data parameter is
available, valid, and unwrapped?
--
J. Charles
> Le 8 juin 2016 à 13:30, Spromicky via swift-evolution < >> swift-evolution@swift.org> a écrit :
>
> 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
Just to clarify : it will crash not because `nil` passed, but because there is no check for `nil` in the function itself. I.e. nobody prevents you to make a function that *will* check the nil and at the same time use all the bonuses from implicitly unwrapped optional parameter:
On 09.06.2016 11:04, Spromicky via swift-evolution wrote:
Yep, but no one stop you if you pass optional value. And in runtime it crash in case if it really will be `nil`. But from other side non-optional params make the same, and does not let you pass an optional value, and show error on compile time. This make your code more safety.
Now force unwrapped params in function used only if you use old Obj-C code without nullability modifiers, so no sense, i think, for clear swift code.
This confused me at the beginning.
But doesn't Int! In parameter type means the function is awaiting an unwrapped value so the user should ensure that it data parameter is available, valid, and unwrapped?
--
J. Charles
Le 8 juin 2016 à 13:30, Spromicky via swift-evolution<swift-evolution@swift.org>a écrit :
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
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:
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.
Sure, and this so confused. For new users its seems like: “Ok, we have optional and non-optional variables in Swift. We can force unwrap optional if we want, or if we sure, that in this moment this variable not `nil`. Now we try write functions.
Non-optional:
func foo(_ bar: Int) {
//...
}
Clear, good!
Now try with optional:
func foo(_ bar: Int?) {
guard let bar = bar else { return }
//...
}
Ok, we can pass optional value in function and implement some default behaviour for `nil`, for example, or whatever. It is have sense. It is cool. It is safety.
Oh! We can set params force unwrap! What it mean? And how it works?
func foo(_ bar: Int!) {
//...
}
Hmmmm… There will be crash if we use `bar` and it will be `nil`. So we must check for `nil` before use. Ok.
func foo(_ bar: Int!) {
guard bar != nil else { return }
//...
}
Oh it is looks safety. But what difference from usual usage of optional? Just only that we not write `let bar = bar` in `guard`?
And if someone else will use my function and will sees in param list force unwrap what he must think? That mean that he can pass optional and all will be checked and fine? Or it mean “yes, you can pass optional, but it was makes just for comfort pass optional without unwrapping, but still not have checks in implementation"
This two cases with force unwrap we can write in other way:
func foo(_ bar: Int) {
//...
}
var i: Int?
//...
foo(i!)
or
func foo(_ bar: Int) {
//...
}
var i: Int?
//...
if let i = i {
foo(i)
}
But now we fully and clearly understand what happening.“
I hope I explained my point. Just wanna add more safety and clarity.
···
Just to clarify : it will crash not because `nil` passed, but because there
is no check for `nil` in the function itself. I.e. nobody prevents you to
make a function that *will* check the nil and at the same time use all the
bonuses from implicitly unwrapped optional parameter:
On 09.06.2016 11:04, Spromicky via swift-evolution wrote:
> Yep, but no one stop you if you pass optional value. And in runtime it crash in case if it really will be `nil`. But from other side non-optional params make the same, and does not let you pass an optional value, and show error on compile time. This make your code more safety.
> Now force unwrapped params in function used only if you use old Obj-C code without nullability modifiers, so no sense, i think, for clear swift code.
>
> > This confused me at the beginning.
> >
> > But doesn't Int! In parameter type means the function is awaiting an unwrapped value so the user should ensure that it data parameter is available, valid, and unwrapped?
> >
> > --
> > J. Charles
> >
> > > Le 8 juin 2016 à 13:30, Spromicky via swift-evolution<swift-evolution@swift.org>a écrit :
> > >
> > > 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
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:
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.
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.
Sure, and this so confused. For new users its seems like: “Ok, we have
optional and non-optional variables in Swift. We can force unwrap optional
if we want, or if we sure, that in this moment this variable not `nil`. Now
we try write functions.
Non-optional:
func foo(_ bar: Int) {
//...
}
Clear, good!
Now try with optional:
func foo(_ bar: Int?) {
guard let bar = bar else { return }
//...
}
Ok, we can pass optional value in function and implement some default
behaviour for `nil`, for example, or whatever. It is have sense. It is
cool. It is safety.
Oh! We can set params force unwrap! What it mean? And how it works?
func foo(_ bar: Int!) {
//...
}
Hmmmm… There will be crash if we use `bar` and it will be `nil`. So we
must check for `nil` before use. Ok.
func foo(_ bar: Int!) {
guard bar != nil else { return }
//...
}
Oh it is looks safety. But what difference from usual usage of optional? Just
only that we not write `let bar = bar` in `guard`?
And if someone else will use my function and will sees in param list force
unwrap what he must think? That mean that he can pass optional and all will
be checked and fine? Or it mean “yes, you can pass optional, but it was
makes just for comfort pass optional without unwrapping, but still not have
checks in implementation"
This two cases with force unwrap we can write in other way:
func foo(_ bar: Int) {
//...
}
var i: Int?
//...
foo(i!)
or
func foo(_ bar: Int) {
//...
}
var i: Int?
//...
if let i = i {
foo(i)
}
But now we fully and clearly understand what happening.“
I hope I explained my point. Just wanna add more safety and clarity.
> Just to clarify : it will crash not because `nil` passed, but because
there
> is no check for `nil` in the function itself. I.e. nobody prevents you to
> make a function that *will* check the nil and at the same time use all
the
> bonuses from implicitly unwrapped optional parameter:
>
> func foo(_ i: Int!) {
> guard i != nil else {return}
>
> print(i) // use IUO parameter
> }
>
> foo(nil) // no errors
> foo(1) // 1
>
>
> > Yep, but no one stop you if you pass optional value. And in runtime it
crash in case if it really will be `nil`. But from other side non-optional
params make the same, and does not let you pass an optional value, and show
error on compile time. This make your code more safety.
> > Now force unwrapped params in function used only if you use old Obj-C
code without nullability modifiers, so no sense, i think, for clear swift
code.
Yes, this is probably the only reason why it was added. The best solution
probably to convert all of these methods to allowing Optional types by
default and then going through them and adding `_Nonnull` on a case-by-case
basis.
···
On Thu, Jun 9, 2016 at 6:40 AM Spromicky via swift-evolution < swift-evolution@swift.org> wrote:
> On 09.06.2016 11:04, Spromicky via swift-evolution wrote:
> >
> > > This confused me at the beginning.
> > >
> > > But doesn't Int! In parameter type means the function is awaiting an
unwrapped value so the user should ensure that it data parameter is
available, valid, and unwrapped?
> > >
> > > --
> > > J. Charles
> > >
> > > > Le 8 juin 2016 à 13:30, Spromicky via swift-evolution< > swift-evolution@swift.org>a écrit :
> > > >
> > > > 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
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:
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.
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.
I don’t even see the purpose of allowing it in Objective-C code that
doesn’t have an annotation. If you can check it against nil, just shadow an
optional with a guard…it’s basically the same code and it’s a lot more
clear on what’s happening.
···
On Mon, Jun 27, 2016 at 11:12 AM Jean-Daniel Dupas via swift-evolution < swift-evolution@swift.org> wrote:
Maybe we can prohibit it in Swift function declaration, and allow it only
when importing native code.
As David, I don’t see any compelling reason to allow such construct in
Swift.
> Le 27 juin 2016 à 10:39, Charlie Monroe via swift-evolution < > swift-evolution@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
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:
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.
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
···
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.
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
>
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 <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
>
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.