Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
+1
We don’t need “return” in single-line closures where the type is known, and
I don’t see why it is required in single-line getters.
Nevin
On Sat, Oct 7, 2017 at 10:07 AM, James Valaitis via swift-evolution < swift-evolution@swift.org> wrote:
Is it widely agreed that it is necessary to require a return statement on
a one line property getter?var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it?
For me it seems redundant; the word `get` literally precedes the closure.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
This has been brought up on the list before. For instance:
Chris Lattner’s response at that time was:
‘Just MHO, but I consider this syntactic sugar, not a fundamental feature
that fits the goal of Swift 4 stage 2.
‘I’m also pretty opposed to doing it at any time. The rationale of
“implicit return” in closures is specifically because they are limited to a
single expression, which makes the semantics “obvious”. This was carefully
considered.’
On Sat, Oct 7, 2017 at 09:18 Nevin Brackett-Rozinsky via swift-evolution < swift-evolution@swift.org> wrote:
+1
We don’t need “return” in single-line closures where the type is known,
and I don’t see why it is required in single-line getters.Nevin
On Sat, Oct 7, 2017 at 10:07 AM, James Valaitis via swift-evolution < > swift-evolution@swift.org> wrote:
Is it widely agreed that it is necessary to require a return statement on
a one line property getter?var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it?
For me it seems redundant; the word `get` literally precedes the closure.
_______________________________________________
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
For what it's worth, you can drop the "get" part for read-only computed
properties and write:
var session: AVCaptureSession { return layer.session }
On Sat, Oct 7, 2017 at 7:07 AM James Valaitis via swift-evolution < swift-evolution@swift.org> wrote:
Is it widely agreed that it is necessary to require a return statement on
a one line property getter?var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it?
For me it seems redundant; the word `get` literally precedes the closure.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
In multi-file projects, re-compiling one file that references the property would necessitate type checking the body of the getter, even if the getter is defined in a different source file. So one reason not to have this would be to avoid slowing down type checking.
Slava
On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution <swift-evolution@swift.org> wrote:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I am going to try to learn how to implement this and submit a proper proposal.
On 7 Oct 2017, at 15:07, James Valaitis <jamesvalaitis@me.com> wrote:
Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
This objection is not applicable, because we are discussing the possibility
to omit “return” exactly when there is a single expression in the getter.
Nevin
On Sat, Oct 7, 2017 at 11:24 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
This has been brought up on the list before. For instance:
Chris Lattner’s response at that time was:
‘Just MHO, but I consider this syntactic sugar, not a fundamental feature
that fits the goal of Swift 4 stage 2.‘I’m also pretty opposed to doing it at any time. The rationale of
“implicit return” in closures is specifically because they are limited to a
single expression, which makes the semantics “obvious”. This was carefully
considered.’
I think the important thing to consider is, what advantage would such a
feature provide *other* than to reduce keystrokes? (I don't personally
think that optimizing for keys pressed by itself should be a goal.)
In the case of closures, single expression closures without "return"
improve readability because such closures are often chained for functional
programming patterns:
someArray.filter { $0.isFloopy }.map { $0.grobber }
Having "return" there would be noise that detracts from understanding
what's going on in that algorithm. It's also worth noting that in this
context, the closure *itself* is also an expression.
In functions, property getters, and subscripts, the same constraints don't
really hold. They're declarations, not expressions, so they don't chain
together and they're not subject to the same readability problems as
closure expressions.
On Sat, Oct 7, 2017 at 9:59 AM Nevin Brackett-Rozinsky via swift-evolution < swift-evolution@swift.org> wrote:
On Sat, Oct 7, 2017 at 11:24 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
This has been brought up on the list before. For instance:
Chris Lattner’s response at that time was:
‘Just MHO, but I consider this syntactic sugar, not a fundamental feature
that fits the goal of Swift 4 stage 2.‘I’m also pretty opposed to doing it at any time. The rationale of
“implicit return” in closures is specifically because they are limited to a
single expression, which makes the semantics “obvious”. This was carefully
considered.’This objection is not applicable, because we are discussing the
possibility to omit “return” exactly when there is a single expression in
the getter.Nevin
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
This is not correct. Omitting the "return" is different from omitting the property's type.
(I'm minorly in favor of allowing the 'return' to be omitted for single-expression getters. Not enough to be the person who implements it, but enough to +1 a proposal-with-implementation even in the Swift 5 timeframe.)
Jordan
On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution <swift-evolution@swift.org> wrote:
Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
In multi-file projects, re-compiling one file that references the property would necessitate type checking the body of the getter, even if the getter is defined in a different source file. So one reason not to have this would be to avoid slowing down type checking.
Consistency? I know I’ve accidentally left out the ‘return’ enough times due to muscle memory from writing closures kicking in, and then had to go back and fix it. Having two different sets of rules for two very similar constructs makes the development process slower.
Charles
On Oct 7, 2017, at 12:22 PM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:
I think the important thing to consider is, what advantage would such a feature provide *other* than to reduce keystrokes? (I don't personally think that optimizing for keys pressed by itself should be a goal.)
I think the important thing to consider is, what advantage would such a feature provide *other* than to reduce keystrokes? (I don't personally think that optimizing for keys pressed by itself should be a goal.)
In the case of closures, single expression closures without "return" improve readability because such closures are often chained for functional programming patterns:
someArray.filter { $0.isFloopy }.map { $0.grobber }
Having "return" there would be noise that detracts from understanding what's going on in that algorithm. It's also worth noting that in this context, the closure *itself* is also an expression.
In functions, property getters, and subscripts, the same constraints don't really hold. They're declarations, not expressions, so they don't chain together and they're not subject to the same readability problems as closure expressions.
Agreed. I would be wary because consistency would push us to allow it in functions also and I’m not sure it makes as much sense there.
On 7 Oct 2017, at 19:22, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:
On Sat, Oct 7, 2017 at 9:59 AM Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:
On Sat, Oct 7, 2017 at 11:24 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
This has been brought up on the list before. For instance:Chris Lattner’s response at that time was:
‘Just MHO, but I consider this syntactic sugar, not a fundamental feature that fits the goal of Swift 4 stage 2.
‘I’m also pretty opposed to doing it at any time. The rationale of “implicit return” in closures is specifically because they are limited to a single expression, which makes the semantics “obvious”. This was carefully considered.’
This objection is not applicable, because we are discussing the possibility to omit “return” exactly when there is a single expression in the getter.
Nevin
_______________________________________________
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
So you’re saying the core team _might_ consider a review if we’ve get a full proposal + implementation in Swift 5 timeframe?
If yes, we only would need someone to implement my proposal. :)
Am 9. Oktober 2017 um 19:54:50, Jordan Rose via swift-evolution (swift-evolution@swift.org) schrieb:
On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution <swift-evolution@swift.org> wrote:
Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
In multi-file projects, re-compiling one file that references the property would necessitate type checking the body of the getter, even if the getter is defined in a different source file. So one reason not to have this would be to avoid slowing down type checking.
This is not correct. Omitting the "return" is different from omitting the property's type.
(I'm minorly in favor of allowing the 'return' to be omitted for single-expression getters. Not enough to be the person who implements it, but enough to +1 a proposal-with-implementation even in the Swift 5 timeframe.)
Jordan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
In multi-file projects, re-compiling one file that references the property would necessitate type checking the body of the getter, even if the getter is defined in a different source file. So one reason not to have this would be to avoid slowing down type checking.
This is not correct. Omitting the "return" is different from omitting the property's type.
(I'm minorly in favor of allowing the 'return' to be omitted for single-expression getters. Not enough to be the person who implements it, but enough to +1 a proposal-with-implementation even in the Swift 5 timeframe.)
I’m minorly opposed, because it feels like a slippery slope. What about function bodies? etc
func foo() -> Int { 3 } // should this be allowed?
Slava
On Oct 9, 2017, at 10:54 AM, Jordan Rose <jordan_rose@apple.com> wrote:
On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution <swift-evolution@swift.org> wrote:
Jordan
Even I would personally want this, this request didn’t made into Swift 3, nor in Swift 4 and is clearly out of scope for Swift 5.
You can read my proposal here which includes all areas where this could be allowed: swift-evolution/nnnn-single-expression-optional-return.md at single_expression_optional_return · DevAndArtist/swift-evolution · GitHub
Here are two posts from Chris Lattner why this feature won’t come any time soon:
- [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions
- [swift-evolution] [Proposal] [Stage–2] `return` consistency for single-expressions
Am 9. Oktober 2017 um 06:56:19, Charles Srstka via swift-evolution (swift-evolution@swift.org) schrieb:
On Oct 7, 2017, at 12:22 PM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:
I think the important thing to consider is, what advantage would such a feature provide *other* than to reduce keystrokes? (I don't personally think that optimizing for keys pressed by itself should be a goal.)
Consistency? I know I’ve accidentally left out the ‘return’ enough times due to muscle memory from writing closures kicking in, and then had to go back and fix it. Having two different sets of rules for two very similar constructs makes the development process slower.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Is it widely agreed that it is necessary to require a return statement on a one line property getter?
var session: AVCaptureSession { get { return layer.session } }
Or could we follow the convention for any other close and get rid of it? For me it seems redundant; the word `get` literally precedes the closure.
In multi-file projects, re-compiling one file that references the property would necessitate type checking the body of the getter, even if the getter is defined in a different source file. So one reason not to have this would be to avoid slowing down type checking.
This is not correct. Omitting the "return" is different from omitting the property's type.
(I'm minorly in favor of allowing the 'return' to be omitted for single-expression getters. Not enough to be the person who implements it, but enough to +1 a proposal-with-implementation even in the Swift 5 timeframe.)
I’m minorly opposed, because it feels like a slippery slope. What about function bodies? etc
func foo() -> Int { 3 } // should this be allowed?
In fact the reason I thought the original thread was about omitting the return type, rather than just omitting the ‘return’, is that I feel the main reason that single-expression closures exist is so that their type can be inferred as part of the expression containing the closure. Swift does not infer types across statement boundaries, so single expression closures exist, as a special case, to help you avoid declaring types in some cases.
Chris will say no, it’s about concision, and omitting the ‘return’, but deep down in his heart, he knows that single-expression closures were really just a type inference hack :-)
Slava
On Oct 10, 2017, at 1:00 PM, Slava Pestov <spestov@apple.com> wrote:
On Oct 9, 2017, at 10:54 AM, Jordan Rose <jordan_rose@apple.com> wrote:
On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution <swift-evolution@swift.org> wrote:
Slava
Jordan
I’m minorly opposed, because it feels like a slippery slope. What about function bodies? etc
func foo() -> Int { 3 } // should this be allowed?
Yes, why not? What is fundamentally different about a function body compared to a getter body (or a closure body ;-)) that means, if we accept it for getters, we should not also accept it for function bodies.
Will this finally bring labels back everywhere (closures and stored
functions too)? :D.
On Thu, Oct 12, 2017 at 3:03 PM, Jeremy Pereira via swift-evolution < swift-evolution@swift.org> wrote:
>
> I’m minorly opposed, because it feels like a slippery slope. What about
function bodies? etc
>
> func foo() -> Int { 3 } // should this be allowed?Yes, why not? What is fundamentally different about a function body
compared to a getter body (or a closure body ;-)) that means, if we accept
it for getters, we should not also accept it for function bodies._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution