[swift-evolution] Auto Unwrapping Of Optionals

[Rod Brown]

I definitely agree there are difficulties with working with nullability and structs. Interesting perspective on how to deal with that. I'd be interested in what others think of your inout type idea.

I think this specific proposal asking for compiler magic to auto-unwrap invisibly and only in very limited cases, as this proposal suggests, ends up breaking a lot more than it fixes. I can only see circumstances of this working with variables in the current scope, as anything like a property could be updated by other methods, threads etc, and the compiler couldn't be certain of state.

I think a language feature like you describe would be a lot more helpful, but I'd love to hear others' views on that.

- Rod

> On 30 Apr 2016, at 5:22 PM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> 
>> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I agree that it's a pain to have to unwrap after this, but this proposal worries me somewhat.
>> 
>> I don't think we can safely guarantee that the value is non-null outside a very limited subset of cases, and we're breaking the simple, general and reasonable syntax of Swift for a very minor convenience win. 
>> 
>> Additionally, this will play out like magic. Suddenly an optional starts dynamically changing its behaviour. I can't see where the compiler begins or ends the assertion of the value's non-null state, and so you have code that, with a little shifting around, begins to fail to even compile, based on something the user cannot see.
>> 
>> I think we have better mechanisms to handle this type of thing, like the if/guard let syntax, and implicitly unwrapped optionals.
> 
> Actually, thinking about it a bit more I think that the main case where I would want something like this is actually, something more like the following:
> 
> 	if var unwrappedFoo = self.foo {
> 		unwrappedFoo.mutate()	// self.foo is unchanged, we have to do this:
> 		self.foo!.mutate()	// original is changed, but unwrappedFoo is not
> 		// foo was changed once, not twice
> 	}
> 
> Of course classes follow different rules, but it’s a little counter-intuitive for structs, what if we could do something like this:
> 
> 	if inout unwrappedFoo = self.foo {
> 		unwrappedFoo.mutate()	// both are changed
> 		self.foo!.mutate()	// no longer required this
> 		// foo was changed twice, and both forms are consistent
> 	}
> 
> i.e- inout in this case gets us a non-optional reference to the original value, not a copy (or potential copy). In the event that self.foo is changed somewhere else, unwrappedFoo would continue to reference to what it used to be and remain usable, though of course in the above example the call to self.foo! would fail in such a case, but it should no longer be required.
> 
> 
> At least in my experience this is the most common case that I encounter, as I try to use if let or guard let (or var) for safety, but then this doesn’t help when manipulating a struct, so a third option could be useful in such cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160430/11040072/attachment.html>