> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution
> <[email protected]> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
