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

[Taras Zakharko]

> 	* What is your evaluation of the proposal?

+1

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

Its not really a problem per se, but an inconsistency, and this proposal does a very good job of addressing it

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

Yes. One of the declared goals for Swift is to streamline the type system and remove idiosyncrasies. This proposal does exactly that

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

I was following the discussion quite closely. 

— Taras


> On 14 Feb 2016, at 03:08, Andrew Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> 
> >       * 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 <mailto: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 <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 <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 <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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> 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/36bbefa9/attachment.html>