[swift-evolution] Computed properties: get and set using shorthand notation?

[T.J. Usiyan]

+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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/489b0f68/attachment.html>