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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
