Under "Proposed solution" you say (emphasis mine): "Make return optional and infer return type for single-expressions everywhere in the language:"
However the return type isn't inferred for computed properties or functions, and I don't see type inference being discussed in the proposal (other than mentioning that closures have it). - David > 31 maj 2016 kl. 19:35 skrev Adrian Zubarev via swift-evolution > <[email protected]>: > > Here is the draft proposal: > https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md > > Did I covered everything case? If you find some mistakes feel free to provide > feedback so I can fix the proposal before I submit a PR. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution > ([email protected]) schrieb: > >> +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 > > _______________________________________________ > 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
