[swift-evolution] Idea: Allow/require "let" in property setter name declarations

[Haravikk]

Actually a setter has more in common with a function, in which case the let implicit, the difference is that a setters type is also implicit. In fact, you don’t even need to specify a name in a setter at all, as the default is newValue and you can just use that.

I’m more curious whether we even need a named new value at all, or if setters should just look like the following instead:

	set { sideLength = $0 / 4.0 }

As this would be more consistent with anonymous closure arguments, rather than using newValue which is arbitrary. I’ve never encountered an occasion where I’ve needed a custom name, and I only use external vs internal names on functions where I can make an external name that flows better, but perhaps doesn’t mesh with my other internal variable names.

> On 6 May 2016, at 12:09, Ian Partridge via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Currently, the syntax for explicitly naming property setters is:
> 
> class Square {
>   var sideLength: Double = 0.0
> 
>   var perimeter: Double {
>     get {
>       return sideLength * 4.0
>     }
>     set(newPerimeter) { // declares newPerimeter parameter, "let" not allowed
>       sideLength = newPerimeter / 4.0
>     }
>   }
> }
> 
> Compare this with how extraction of associated values from enumerations looks:
> 
> enum ServerResponse {
>   case Failure(String)
>   case Result(Int)
> }
> let response = ServerResponse.Result(404)
> 
> switch response {
> case .Failure(let reason): // let is required here
>   print(reason)
> case .Result(let code):
>   print(code)
> }
> 
> For consistency, would it be better to allow/require:
> 
> class Square {
>   var sideLength: Double = 0.0
> 
>   var perimeter: Double {
>     get {
>       return sideLength * 4.0
>     }
>     set(let newPerimeter) {  // declares newPerimeter parameter
>         sideLength = newPerimeter / 4.0
>     }
>   }
> }
> 
> The idea would apply to didSet{} and willSet{} too.
> 
> -- 
> Ian Partridge
> 
> _______________________________________________
> 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/20160506/dd162e21/attachment.html>