On 14 Feb 2016, at 03:08, Andrew Bennett via swift-evolution <swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution