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-evolut...@haravikk.me> wrote:
>
>
>> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution
>> <swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
