[Idea] return if / return unless

juliand665 · August 4, 2016, 1:38pm

How often have you written something like the following?

`
if indexPath.row == 0 { return }

guard let thing = things[index] else { return nil }
`

I propose adding some syntactic sugar to make such statements more readable and simple to write:

`
return if indexPath.row == 0

return nil unless let thing = things[index]
`

I don’t know how easy or hard this would be to implement, but I think it would improve some code significantly.

–Julian Dunskus

Brent_Royal-Gordon · August 4, 2016, 11:24pm

On the `unless` part, at least, see the "Rename guard to unless" section in Commonly Rejected Changes: <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>

···

On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution <swift-evolution@swift.org> wrote:

return nil unless let thing = things[index]

--
Brent Royal-Gordon
Architechies

Christian_Kienle · August 4, 2016, 2:31pm

+1

···

2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution < swift-evolution@swift.org>:

How often have you written something like the following?

`
if indexPath.row == 0 { return }

guard let thing = things[index] else { return nil }
`

I propose adding some syntactic sugar to make such statements more
readable and simple to write:

`
return if indexPath.row == 0

return nil unless let thing = things[index]
`

I don’t know how easy or hard this would be to implement, but I think it
would improve some code significantly.

–Julian Dunskus

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Mit freundlichen Grüßen

*Christian Kienle*
Mobile Developer

*REWE Digital GmbH*
Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender),
Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450

Telefon: +49 151 11441782
E-Mail: christian.kienle@rewe-digital.com
Internet: *www.rewe-digital.com <http://www.rewe-digital.com/>\*

Ein Unternehmen der *REWE GROUP*

Kurt_Werle · August 4, 2016, 2:52pm

Why would you do this just for return statements? Why not do postfix
conditionals for all statements (like ruby)?

I've always liked postfix conditionals, but not enough to suggest them.
Mostly I'm curious about limiting the scope to return statements.

···

On Thu, Aug 4, 2016 at 7:31 AM, Christian Kienle via swift-evolution < swift-evolution@swift.org> wrote:

+1

2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution <
swift-evolution@swift.org>:

How often have you written something like the following?

`
if indexPath.row == 0 { return }

guard let thing = things[index] else { return nil }
`

I propose adding some syntactic sugar to make such statements more
readable and simple to write:

`
return if indexPath.row == 0

return nil unless let thing = things[index]
`

I don’t know how easy or hard this would be to implement, but I think it
would improve some code significantly.

–Julian Dunskus

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Mit freundlichen Grüßen

*Christian Kienle*
Mobile Developer

*REWE Digital GmbH*
Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender),
Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450

Telefon: +49 151 11441782
E-Mail: christian.kienle@rewe-digital.com
Internet: *www.rewe-digital.com <http://www.rewe-digital.com/>\*

Ein Unternehmen der *REWE GROUP*
http://www.rewe-group.com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
kurt@CircleW.org
http://www.CircleW.org/kurt/

dabrahams · August 4, 2016, 11:46pm

-1 from me. Postfix conditionals are easily mistaken for unconditional
statements when reading quickly. IMO always having the condition first
improves clarity. Furthermore, postfix conditionals don't solve any
real problem in Swift AFAICT.

···

on Thu Aug 04 2016, Kurt Werle <swift-evolution@swift.org> wrote:

Why would you do this just for return statements? Why not do postfix
conditionals for all statements (like ruby)?

I've always liked postfix conditionals, but not enough to suggest them.

--
-Dave

David_Ronnqvist · August 4, 2016, 3:03pm

One complication with allowing postfix conditionals for all statements is that it often needs to have an else clause as well (like the ternary operator “?:").

For example, what’s the type of “x” below?

let x = 5 if someCriteria()

And is “y” initialized or not?

let y: Int
y = 42 if someCriteria()
doSomething(with: y)

I realize that this idea is more about the feature/behavior than the naming, but renaming “guard” to “unless” is one of the commonly rejected proposals.

github.com

apple/swift-evolution/blob/main/commonly_proposed.md

# Commonly Rejected Changes 

This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://forums.swift.org/t/brace-syntax/678/3): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.

 * [Remove `;` semicolons](https://forums.swift.org/t/proposal-to-remove-semicolons/523/3): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://forums.swift.org/t/change-the-name-of-the-boolean-operators/30/2), and [allow non-punctuation operators](https://forums.swift.org/t/allowing-characters-for-use-as-custom-operators/952) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://forums.swift.org/t/ternary-operator-suggestion/49/148): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

- David

···

On 04 Aug 2016, at 16:52, Kurt Werle via swift-evolution <swift-evolution@swift.org> wrote:

Why would you do this just for return statements? Why not do postfix conditionals for all statements (like ruby)?

I've always liked postfix conditionals, but not enough to suggest them. Mostly I'm curious about limiting the scope to return statements.

On Thu, Aug 4, 2016 at 7:31 AM, Christian Kienle via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1

2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
How often have you written something like the following?

`
if indexPath.row == 0 { return }

guard let thing = things[index] else { return nil }
`

I propose adding some syntactic sugar to make such statements more readable and simple to write:

`
return if indexPath.row == 0

return nil unless let thing = things[index]
`

I don’t know how easy or hard this would be to implement, but I think it would improve some code significantly.

–Julian Dunskus

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Mit freundlichen Grüßen

Christian Kienle
Mobile Developer

REWE Digital GmbH
Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender), Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450

Telefon: +49 151 11441782
E-Mail: christian.kienle@rewe-digital.com <mailto:christian.kienle@rewe-digital.com>
Internet: www.rewe-digital.com <http://www.rewe-digital.com/>

Ein Unternehmen der REWE GROUP
http://www.rewe-group.com <http://www.rewe-group.com/>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
kurt@CircleW.org
Welcome to circlew.org <Welcome to circlew.org;
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

juliand665 · August 5, 2016, 12:11am

I read that, see paragraph three of the email you replied to (my second in this thread)

···

On 05 Aug 2016, at 01:24, Brent Royal-Gordon <brent@architechies.com> wrote:

On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution <swift-evolution@swift.org> wrote:

return nil unless let thing = things[index]

On the `unless` part, at least, see the "Rename guard to unless" section in Commonly Rejected Changes: <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>

juliand665 · August 4, 2016, 3:41pm

Having postfix conditionals for return would be a lot easier to implement than having them everywhere, because you just need to watch for an if or unless after the return. Of course they might come in handy elsewhere, and may even solve the ever-present problem of the unintuitive ternary operator ?:, but that’s a whole different discussion. This proposal is simply about having some syntactic sugar for return statements.

Seeing as this change would be purely additive and adding more keywords to Swift is not really a problem (we can use them as parameter labels etc.), I don’t really see a reason against it.

Using “unless” for this makes sense especially as a postfix. I agree with keeping guard around, but this statement is different from guard in that the code executed if the condition can’t be satisfied is stated before the keyword, which makes it read well.

In case of the guard statement, you’d need another keyword to make “unless” logical, like unless foo != nil inWhichCase {}, which just feels bulky to me.

Additionally, return nil guard let thing = things[index] does not read logically to me.

–Julian

···

On 04 Aug 2016, at 17:03, David Rönnqvist via swift-evolution <swift-evolution@swift.org> wrote:

One complication with allowing postfix conditionals for all statements is that it often needs to have an else clause as well (like the ternary operator “?:").

For example, what’s the type of “x” below?

let x = 5 if someCriteria()

And is “y” initialized or not?

let y: Int
y = 42 if someCriteria()
doSomething(with: y)

I realize that this idea is more about the feature/behavior than the naming, but renaming “guard” to “unless” is one of the commonly rejected proposals.
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

- David

On 04 Aug 2016, at 16:52, Kurt Werle via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Why would you do this just for return statements? Why not do postfix conditionals for all statements (like ruby)?

I've always liked postfix conditionals, but not enough to suggest them. Mostly I'm curious about limiting the scope to return statements.

On Thu, Aug 4, 2016 at 7:31 AM, Christian Kienle via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1

2016-08-04 15:38 GMT+02:00 Julian Dunskus via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
How often have you written something like the following?

`
if indexPath.row == 0 { return }

guard let thing = things[index] else { return nil }
`

I propose adding some syntactic sugar to make such statements more readable and simple to write:

`
return if indexPath.row == 0

return nil unless let thing = things[index]
`

I don’t know how easy or hard this would be to implement, but I think it would improve some code significantly.

–Julian Dunskus

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Mit freundlichen Grüßen

Christian Kienle
Mobile Developer

REWE Digital GmbH
Domstraße 20, 50668 Köln, Büro: Schanzenstr. 6-20, 51063 Köln
Geschäftsführer: Dr. Jean-Jacques Michel van Oosten (Vorsitzender), Christoph Eltze, Dr. Johannes Steegmann, Dr. Robert Zores
Handelsregister: Amtsgericht Köln (HRB 78670) UST-ID-Nr.: DE 290 605 450

Telefon: +49 151 11441782
E-Mail: christian.kienle@rewe-digital.com <mailto:christian.kienle@rewe-digital.com>
Internet: www.rewe-digital.com <http://www.rewe-digital.com/>

Ein Unternehmen der REWE GROUP
http://www.rewe-group.com <http://www.rewe-group.com/>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
kurt@CircleW.org <mailto:kurt@circlew.org>
Welcome to circlew.org <http://www.circlew.org/kurt/>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

juliand665 · August 5, 2016, 2:48pm

I don’t agree with that. To me, everything between return and if (including the return itself) only being executed if the condition is true seems like the logical way of interpreting that syntax.

I do, however, see how people skimming through code might be confused, but a return with code after it should make it obvious that there’s more to it than always returning at that point.

···

On 05 Aug 2016, at 04:58, rintaro ishizaki <fs.output@gmail.com> wrote:

Limiting for `return` introduces another problem.

mutating func increment() -> Val {
self = self.incremented()
return self
}

return val.increment() if val == sentinel
print(val)

I think, it's not obvious `val` after `return ... if` is incremented or not.

2016-08-05 9:11 GMT+09:00 Julian Dunskus via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
On 05 Aug 2016, at 01:24, Brent Royal-Gordon <brent@architechies.com <mailto:brent@architechies.com>> wrote:
>
>> On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> return nil unless let thing = things[index]
>
> On the `unless` part, at least, see the "Rename guard to unless" section in Commonly Rejected Changes: <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>
>

I read that, see paragraph three of the email you replied to (my second in this thread)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution