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 ([email protected]
<mailto:[email protected]>) 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
<[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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
