+1 L
On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution <[email protected]> wrote: > >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
