[swift-evolution] [Review] SE-0031 Adjusting inout Declarations for Type Decoration

[Andrew Bennett]

>       * What is your evaluation of the proposal?

+0.5 A good improvement. I think it could be made less special-case, but
that can be built on top of this. See my next comments for more details.

>       * Is the problem being addressed significant enough to warrant a
change to Swift?

Not a major problem, but an incremental improvement with easy migration and
no negative impact.

>       * Does this proposal fit well with the feel and direction of Swift?

Yes, although I think it needs a little more work before it's properly
Swifty.

We are now saying it's part of the argument's type, but that type is *only*
an argument type, you cannot use that type elsewhere. I can see this as
being confusing for people unfamiliar with inout. When it's part of the
label it's obvious it's only usable as an argument.

If we can do this:

func foo(a: B)
var b: B


Why can't we do this?

func foo(a: inout B)

var b: inout B


I'd like to see a reference modifier for types that can be used elsewhere.

It seems reasonable to be able to refer to the inout type outside of an
argument context.

I presume that this:

func test(inout a: Int) {

    a = 456

}

var a = 123

test(&a)


Is roughly equivalent to something like this:

class Reference<T> {

    var value: T

    init(value: T) { self.value = value }

}

func test(a: Reference<Int>) {

    a.value = 456

}

var b = 123

var bRef = Reference(value: b)

test(bRef)

b = bRef.value


I'd be happy if *inout* it was implemented something like this, and there
were optimisations introduced to ensure this was done as efficiently as
inout currently is.

See *potential future work* below for details.

>       * If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

It's roughly similar to a few other languages I've used, it seems
consistent to make it about the argument's type.

>       * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I read through and considered the implications of making inout more
explicitly part of the argument type, instead of just the function's type.

*Potential future work:*

It seems to me that *inout*/*&* are to *?* what *Reference<T>* is to
*Optional<T>*. We already have the *indirect* keyword on enums, perhaps
*indirect, **inout*, and *&* should all be combined into one concept.

&Type is equivalent to:

Reference<Type>


test(&foo) is equivalent to:

var fooRef = Reference(value: foo)

test(fooRef)

foo = fooRef.value


Similar to optionals you could have syntactic sugar to get and set the
value, simplifying this to:

var fooRef = &foo

test(fooRef)

foo = fooRef


With an enum instead of using indirect you could use Reference<T>.

*Potential issues:*

I'm not sure if it will be confusing that using *&* in a declaration makes
a copy; using *&* in an argument makes a copy, then copies it back after
the call. Also this could be confusing if you're used to
pointers/references and expect changing foo to change the value of
`fooRef`. This may be solved if foo is aliased to fooRef for the lifetime
of fooRef, however that may be confusing for users that aren't used
to pointers/references.

There's also the issue of what to do if someone writes &&foo, does this
make any sense as it's not really a pointer, and you cannot offset it? I
think that calling & on a reference type would have to be identity.

*Potential future-future work:*
Make the distinction between struct and class stop at SIL, implement them
on top of a Reference<T> style type (with compiler support), then use
something akin to property behaviours to implement inheritance,
overloading, etc.

Any simplifications/generalisations like this should only really be done if
they don't make it harder to interpret error messages.

On Friday, 12 February 2016, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> Hello Swift community,
>
> The review of "Adjusting inout Declarations for Type Decoration" begins
> now and runs through February 15th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>         * What is your evaluation of the proposal?
>         * Is the problem being addressed significant enough to warrant a
> change to Swift?
>         * Does this proposal fit well with the feel and direction of Swift?
>         * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>         * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
>         https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160214/7e5a9905/attachment.html>