Feel free to convince the core team to add such a list. ;)
-- Adrian Zubarev Sent with Airmail Am 1. Juni 2016 um 19:17:25, Vladimir.S (sva...@gmail.com) schrieb: Do we have any 'feature' to not just throw away of proposals(and then scan mail list and remember), but put them in queue of proposals that should be reviewed after Swift 3 is released? Probably some list of such proposals on site, don't know. So I believe any proposal that would be raised now and got support from community - should be added to that queue on some page somewhere on swift.org On 01.06.2016 20:03, Adrian Zubarev via swift-evolution wrote: > Given that Swift 3 is winding down, we are in a mode of declining PRs > for proposals that don’t align with its goals. Please bring this back > up for discussion this fall, thanks for understanding. > > Closed by Chris. Sad but we’ll have to wait a little longer for this change. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 1. Juni 2016 um 06:58:27, Thorsten Seitz (tseit...@icloud.com > <mailto:tseit...@icloud.com>) schrieb: > >> +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 >> > <swift-evolution@swift.org>: >> > >> > 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 >> >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: >> >> >> >>> +1 >> >>> >> >>> L >> >>> >> >>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution >> >>> <swift-evolution@swift.org> wrote: >> >>> > >> >>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution >> >>> >> <swift-evolution@swift.org> 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 >> >>> >>> <swift-evolution@swift.org> wrote: >> >>> >>> >> >>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution >> >>> >>> <swift-evolution@swift.org> 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 >> >>> >>> swift-evolution@swift.org >> >>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> >> >> >>> >> _______________________________________________ >> >>> >> swift-evolution mailing list >> >>> >> swift-evolution@swift.org >> >>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> > >> >>> > _______________________________________________ >> >>> > swift-evolution mailing list >> >>> > swift-evolution@swift.org >> >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >>> _______________________________________________ >> >>> swift-evolution mailing list >> >>> swift-evolution@swift.org >> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> >> >> >> >> _______________________________________________ >> >> swift-evolution mailing list >> >> swift-evolution@swift.org >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ >> > swift-evolution mailing list >> > swift-evolution@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
