Computed properties: get and set using shorthand notation?


(Chris Liscio) #1

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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com <http://supermegaultragroovy.com/>
Learn _your_ music with Capo: http://capoapp.com <http://capoapp.com/>


(Jessy) #2

+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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com <http://supermegaultragroovy.com/>
Learn _your_ music with Capo: http://capoapp.com <http://capoapp.com/>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #3

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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com
Learn _your_ music with Capo: http://capoapp.com

--
  -- Howard.


(TJ Usiyan) #4

+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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com
Learn _your_ music with Capo: http://capoapp.com

_______________________________________________
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


(Jessy) #5

I consider

func posF(x: Int) -> Int { return max(0, x) }

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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com <http://supermegaultragroovy.com/>
Learn _your_ music with Capo: http://capoapp.com <http://capoapp.com/>

--
  -- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Liscio) #6

Jessy,

+1 on implicit return

Yay!

-1 on $0; I like newValue more than it.

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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com <http://supermegaultragroovy.com/>
Learn _your_ music with Capo: http://capoapp.com <http://capoapp.com/>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jessy) #7

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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com <http://supermegaultragroovy.com/>
Learn _your_ music with Capo: http://capoapp.com <http://capoapp.com/>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jonathan Tang) #8

+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.

Thanks!

Chris Liscio
http://supermegaultragroovy.com
Learn _your_ music with Capo: http://capoapp.com

_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution