Why can’t we use shorthand argument names and implicit returns when specifying the get and set blocks in a computed property? I.e., Why must we refer to newValue in the implementation of set, and not $0 like we do in closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I searched the archives and didn’t turn up anything that referred to this specifically.
+1 on implicit return
-1 on $0; I like newValue more than it.
I also think the return type should be implicit.
···
On Feb 3, 2016, at 5:00 PM, Chris Liscio via swift-evolution <swift-evolution@swift.org> wrote:
Why can’t we use shorthand argument names and implicit returns when specifying the get and set blocks in a computed property? I.e., Why must we refer to newValue in the implementation of set, and not $0 like we do in closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I searched the archives and didn’t turn up anything that referred to this specifically.
You can keep going on this line of thinking, e.g.:
let posC = { max(0, $0) }
Is legal but you have to write:
func posF(x: Int) -> Int { return max(0, x) }
···
On Thursday, 4 February 2016, Chris Liscio via swift-evolution < swift-evolution@swift.org> wrote:
Why can’t we use shorthand argument names and implicit returns when
specifying the get and set blocks in a computed property? I.e., Why must we
refer to newValue in the implementation of set, and not $0 like we do in
closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another
class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I
searched the archives and didn’t turn up anything that referred to this
specifically.
+1 for both. I don't think that I would prefer the $0 syntax in most cases
but I would appreciate making the syntax more consistent.
TJ
···
On Wed, Feb 3, 2016 at 5:08 PM, Jessy Catterwaul via swift-evolution < swift-evolution@swift.org> wrote:
+1 on implicit return
-1 on $0; I like newValue more than it.
I also think the return *type* should be implicit.
On Feb 3, 2016, at 5:00 PM, Chris Liscio via swift-evolution < > swift-evolution@swift.org> wrote:
Why can’t we use shorthand argument names and implicit returns when
specifying the get and set blocks in a computed property? I.e., Why must we
refer to newValue in the implementation of set, and not $0 like we do in
closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another
class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I
searched the archives and didn’t turn up anything that referred to this
specifically.
to be a precursor to the syntax we’ll eventually have:
func posF(Int) {max(0, $0)}
···
On Feb 3, 2016, at 5:29 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:
You can keep going on this line of thinking, e.g.:
let posC = { max(0, $0) }
Is legal but you have to write:
func posF(x: Int) -> Int { return max(0, x) }
On Thursday, 4 February 2016, Chris Liscio via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Why can’t we use shorthand argument names and implicit returns when specifying the get and set blocks in a computed property? I.e., Why must we refer to newValue in the implementation of set, and not $0 like we do in closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I searched the archives and didn’t turn up anything that referred to this specifically.
Well, my problem with newValue is the lack of consistency with everywhere else. If we’re not specifying names, then $0 feels “more like the rest of the language” than newValue does.
If you preferred to use newValue (or any other name), you could still do:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set(newValue) { _wrapped.property = newValue }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
So it wouldn’t really stomp on anything too valuable IMO.
I also think the return type should be implicit.
An implicit return type could certainly be nice as well.
Chris
···
On Feb 3, 2016, at 5:08 PM, Jessy Catterwaul <mr.jessy@gmail.com> wrote:
On Feb 3, 2016, at 5:00 PM, Chris Liscio via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Why can’t we use shorthand argument names and implicit returns when specifying the get and set blocks in a computed property? I.e., Why must we refer to newValue in the implementation of set, and not $0 like we do in closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I searched the archives and didn’t turn up anything that referred to this specifically.
If functions start using shorthand argument names, I would probably feel more comfortable with it. Is that being discussed?
···
On Feb 3, 2016, at 5:22 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:
+1 for both. I don't think that I would prefer the $0 syntax in most cases but I would appreciate making the syntax more consistent.
TJ
On Wed, Feb 3, 2016 at 5:08 PM, Jessy Catterwaul via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 on implicit return
-1 on $0; I like newValue more than it.
I also think the return type should be implicit.
On Feb 3, 2016, at 5:00 PM, Chris Liscio via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Why can’t we use shorthand argument names and implicit returns when specifying the get and set blocks in a computed property? I.e., Why must we refer to newValue in the implementation of set, and not $0 like we do in closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I searched the archives and didn’t turn up anything that referred to this specifically.
+1 for both. I find that I use $0 enough in closures that I have no
problem remembering what it does, and being able to use it for setters
would save me a bunch of typing.
···
On Wed, Feb 3, 2016 at 2:24 PM, Jessy Catterwaul via swift-evolution < swift-evolution@swift.org> wrote:
If functions start using shorthand argument names, I would probably feel
more comfortable with it. Is that being discussed?
On Feb 3, 2016, at 5:22 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:
+1 for both. I don't think that I would prefer the $0 syntax in most cases
but I would appreciate making the syntax more consistent.
TJ
On Wed, Feb 3, 2016 at 5:08 PM, Jessy Catterwaul via swift-evolution < > swift-evolution@swift.org> wrote:
+1 on implicit return
-1 on $0; I like newValue more than it.
I also think the return *type* should be implicit.
On Feb 3, 2016, at 5:00 PM, Chris Liscio via swift-evolution < >> swift-evolution@swift.org> wrote:
Why can’t we use shorthand argument names and implicit returns when
specifying the get and set blocks in a computed property? I.e., Why must we
refer to newValue in the implementation of set, and not $0 like we do in
closures? Also, why do we need ‘return’?
Once you get used to the shorthand, you kinda want to use it all over…
This question came up recently when I was writing a façade for another
class, and would have liked to written something like the following:
class Façade {
private var _wrapped: Something
var wrappedProperty: Int {
get { _wrapped.property }
set { _wrapped.property = $0 }
}
var multipliedProperty: Int { _wrapped.property * 42 }
}
I apologize if this has already been discussed/requested before. I
searched the archives and didn’t turn up anything that referred to this
specifically.