+1 `return` in guards should stay, because there one has to use either `return`, `continue` or `break`. It would be ugly and inconsistent if one of these could be left out.
-Thorsten > Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution > <[email protected]>: > > I really like the proposal in case of properties and functions, but I really > don't want to have > guard boolean else { "false" } > > I feel like `return` is very important part of `guard` statement. > I understand the requirement for consistency with > properties/closures/functions, but I'll prefer to have some inconsistency in > language in this case and require `return` for `guard`. And in case I'll have > to choose all-or-nothig, I'll give -1 for the proposal. > > I.e. IMO current `return` in properties and functions is less evil than > absent of `return` in `guard`. > >> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote: >> 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] <mailto:[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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
