> On May 31, 2016, at 12:35 PM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > Here is the draft proposal: > https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md > > <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. > >
This is a good start. "Make return optional and infer return type for single-expressions everywhere in the language:” Everywhere in the language is too strong. We should be more precise. I believe we are talking about top level code blocks that only contain a single expression for the following constructs in the grammar: function-body getter-setter-block getter-clause variable-declaration subscript-declaration Please remove the section on guard as any of the preceding will never have single expression top level code blocks if they contain a guard clause. -Matthew > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> +1 >> >> L >> >> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[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 >> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] <mailto:[email protected]> >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
