> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution > <[email protected]> wrote: > > It isn’t a special case because all other single-statement closures in the > language work that way. It’s actually inconsistent now.
Computed properties aren’t closures so it’s not inconsistent in that sense. But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar. It would be nice to see this sugar consistently allowed everywhere in the language. > >> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution >> <[email protected]> wrote: >> >> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution >> <[email protected]> wrote: >> >>> The idea is simple: >>> >>> • Can we make return keyword optional in cases like this? >>> • Shouldn’t this behave like @autoclosure or @noescape? >>> type A { >>> var characters: [Character] = … >>> var string: String { String(self.characters) } >>> var count: Int { 42 } >>> } >>> >>> Is this worth a proposal or Swifty enough, what do you think? >>> >>> Sure I could write return, but why do we allow this behavior for @noescape >>> functions like map!? >> >> While I am not necessarily against this idea, I do wonder if it’s worth >> making what’s going on here less obvious simply for the sake of being able >> to omit a six character keyword. As I understand it, one of the reasons >> ++/-- were removed was due to the increased "burden to learn Swift as a >> first programming language.” This is the sort of thing that becomes another >> one of those special cases that has to be explained to someone new to Swift. >> >> /brian >> >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
