I don't think that removing "switch(self)" would remove much boilerplate. I rather see the returns and cases as such.
It is true your second approach is much more maintainable if you want to add or remove a case. However I think it suffers from readability and you cannot group related logic inside computed properties. So the upcoming boilerplate is much bigger than the one you're about to remove. In addition if you always use exhaustive switches the maintainability isn't that bad. - Maximilian Am 24.03.2016 um 02:22 schrieb Brent Royal-Gordon <[email protected]>: >> enum Suit: Int { >> case Hearts, Spades, Diamonds, Clubs >> >> static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] } >> >> var description: String { >> return match(self) { >> case .Hearts: "♥️" >> case .Spades: "♠️" >> case .Diamonds: "♦️" >> case .Clubs: "♣️" >> } >> } >> >> var isRed: Bool { >> return match(self) { >> case .Hearts, .Diamonds: true >> case .Spades, .Clubs: false >> } >> } >> } > > This attacks the `return` boilerplate rather than the `switch` boilerplate. > That means that, while it helps in this case, it would not help with members > which have complicated logic or side effects. (And technically, the > boilerplate is still there—it's just a `match(self)` instead of a `switch > self`. I feel like they're orthogonal issues. > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
