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
