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

Ah, I understand now; that’s a good point. On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe wrote: > To use the parameters, the function would have to check for nil anyways, > right (or risk a crash at runtime)? If the parameter is changed from an IUO > to an Optional,

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

> To use the parameters, the function would have to check for nil anyways, > right (or risk a crash at runtime)? If the parameter is changed from an IUO > to an Optional, the check for nil simply becomes a shadowing with guard. And what if the overridden method returns "T!"? It would become T?

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

To use the parameters, the function would have to check for nil anyways, right (or risk a crash at runtime)? If the parameter is changed from an IUO to an Optional, the check for nil simply becomes a shadowing with guard. Saagar Jha > On Jul 20, 2016, at 21:10, Chris Lattner

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

> On Jul 20, 2016, at 5:24 PM, Saagar Jha wrote: > > 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 >

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

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

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

Oh, no, they’re just external function parameter names that I put to try to make it more clear. Looks like it didn’t really work :) Saagar Jha > On Jul 20, 2016, at 17:19, William Jon Shipley > wrote: > > Are “forceUnwrapping” and “withoutUnwrapping” special

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

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___ swift-evolution mailing list swift-evolution@swift.org

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

(Comments inline) Saagar Jha > On Jul 20, 2016, at 16:47, Saagar Jha wrote: > > > > On Wed, Jul 20, 2016 at 12:52 PM Chris Lattner > wrote: > On Jul 19, 2016, at 3:46 PM, Saagar Jha

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

> On Jul 20, 2016, at 12:52 PM, Chris Lattner wrote: > > On Jul 19, 2016, at 3:46 PM, Saagar Jha > wrote: >> >> I have updated the proposal here >> .

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

On Jul 19, 2016, at 3:46 PM, Saagar Jha wrote: > > I have updated the proposal here > . Since > this is a potentially a source breaking change, I’d like this to be > considered for Swift 3; unless

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

I have updated the proposal here . 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

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

Gave me a chuckle, but yeah, basically. On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley < w...@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

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

On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution 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

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

Sorry, but I’m going to use your use case as an example…hope you don’t take it personally :) Basically, your use of IUOs is exactly what I’m trying to avoid. IUOs may have their uses, but in my mind, they don’t (in my mind) indicate “This argument should not be nil on most occasions, but may be

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

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

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

The only reason I can think of writing a function with a force-unwrapped parameter is overriding an API function with such a signature, as Chris mentioned. If the function actually doesn’t accept nil you might feel obliged to start the function with something like precondition( IUO argument

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

On Jun 28, 2016, at 10:04 PM, Saagar Jha 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’

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

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 > wrote: Alright, I’ve written it up a proposal; you can find it here

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

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

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

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 wrote: > Hi Saagar, > > If I understand

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

> 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

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

> On Jun 27, 2016, at 4:42 PM, Saagar Jha via swift-evolution > wrote: > > Alright, I’ve written it up a proposal; you can find it here > . This is > my first proposal (and anyways I’ve been told

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

Alright, I’ve written it up a proposal; you can find it here . 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

Re: [swift-evolution] [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

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

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

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

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

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

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

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

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 > a écrit : > > When

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

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

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

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

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

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

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

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

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

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"

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

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!) public func gai_strerror(_: Int32) ->

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

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()

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

> On Jun 10, 2016, at 7:43 PM, Dave Abrahams via swift-evolution > wrote: > > on Thu Jun 09 2016, Saagar Jha wrote: > >> Yes, that’s exactly my point. Force unwrapping optionals adds >> confusion for new users; all too often I see

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

on Thu Jun 09 2016, Saagar Jha 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

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

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. On Thu, Jun 9, 2016 at 6:40 AM Spromicky via swift-evolution < swift-evolution@swift.org>

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

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) { //... }

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

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:

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

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

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

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 <

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

+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.

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

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] [Proposal] Remove force unwrapping in function signature.

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