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


(Chris Lattner) #1

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


(Brent Royal-Gordon) #2

  https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md

  * What is your evaluation of the proposal?

I like it. The current positioning made sense when we still had `var` in that slot, but now that we don't, having it decorate the type seems better.

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

It's not a major problem, but fixing it isn't a major problem either.

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

Yes. I can see a few nice directions we can go with this.

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

For some reason, in my experience inout parameters are usually either built from a different, often very advanced, language feature (like references or pointers), or their syntax is idiosyncratic and unprincipled. It's nice to see Swift attempting to do something rational here.

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

A quick reading, nothing special.

···

--
Brent Royal-Gordon
Architechies


(Joseph Lord) #3

+1

Feels like part of the type to me. Ability for it to be in the type definition of the function is a big plus.

Joseph

···

On Feb 11, 2016, at 11:21 PM, Chris Lattner via swift-evolution <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


(Patrick Gili) #4

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?

With the removal of "let" and "var" from function parameters, this seems to make sense.

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

Yes.

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

Yes.

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

In a loose way, it is similar to C# and Java. This is exactly the way Ada does it.

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

Only read the proposal once, but it is straightforward.

···

On Feb 11, 2016, at 6:21 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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


(Andrew Bennett) #5

      * 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> 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


(Ricardo Parada) #6

The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md

   * What is your evaluation of the proposal?

+1

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

I think so. This is already explained in the proposal.

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

Yes and it appears that it will help the language move forward.

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

Swift is different from other languages and more powerful in naming functions and their parameters. So it is difficult to compare.
The placement of the inout is difficult as the current placement conflicts with parameter labels. The new placement seems to resolve that conflict and still looks good.

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

Quick read.


(Howard Lovatt) #7

+1 for me. Much more logical.

  -- Howard.

···

On 12 February 2016 at 10:21, Chris Lattner via swift-evolution < 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


(Rudolf Adamkovič) #8

+1 Much better!

···

Sent from my iPhone

On 12 Feb 2016, at 00:21, Chris Lattner <clattner@apple.com> 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-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Taras Zakharko) #9

  * 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@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