Pitch: Multi-statement if/switch/do expressions

roydaw · 2023-12-01T22:47:07.079Z

Thanks for taking the time to read my response

tera · 2023-12-02T02:15:05.462Z

Was it suggested already to use the compulsory parens for the multi-statement expression?

let x = if condition {
    print("something")
    (1)  // parens are compulsory here
} else if otherCondition {
    2    // single statement, no parens needed
} else {
    (3)  // but we could still use them if we want so
}

We do have a precedent of using parens "to disambiguate" somewhere if memory serves me right. It would be low enough ceremony and no new keyword is needed.

If the keyword, in addition to what has been discussed so far we could add "result".

wadetregaskis · 2023-12-02T02:33:45.852Z

Hmm, an interesting idea. Definitely novel.

It might be a challenge for the parser because of ambiguity with function calls…?

It's further overloading an already overloaded part of the syntax, since parentheses are used for specifying operator ordering as well, among several other applications. The common thread between the existing applications is that parentheses group things together, which is not what they'd be doing in this use.

From a typing perspective it's more work to write than just then or use because it requires coordinating multiple keys in combos, on most keyboards (shift + 9, shift + 0), and it splits the 'keyword' in two.

To my knowledge it doesn't have precedence in other notable languages, which is a good thing in this case since that then won't encourage misinterpretation of the meaning, although I'm not sure it's intuitive, either. It looks like how ordered lists, or footnotes / references, are often written in text fields with limited formatting support, when used with integers.

Nevin · 2023-12-02T04:09:27.614Z

Ben_Cohen:

Not up for discussion is whether features like type inference, implicit returns from single-expression functions, or single-expression if/switch expressions are even a good feature in the first place. These features are not to some folk's taste. That's fine. But they are a settled part of the Swift language.

I am glad you wrote this. It is an excellent point, highly relevant, and completely true.

The features you listed are part of the language and cannot be removed. They will remain there forever, as will all other language features. That is the reality of how Swift evolution works: things can be added, but never taken away.

And if the proposed multi-statement expression idea were to become a language feature, then it too would remain part of Swift forever, unable to be removed at a later date regardless of how it turns out in practice and with hindsight.

Thus, until and unless we become absolutely certain that this is definitely something we will want in the language forever and always, it is imperative that we must not add it.

• • •

Judging by the discussion in this thread, it is abundantly clear to me that we do not have any sort of agreement in that regard. A substantial number of respondents have expressed that they view this as an anti-feature, which would promote disorganized code, decrease readability, and generally run counter to Swift’s guiding principles.

And even among those who support the idea, there are a multitude of camps promoting different keywords or lack thereof, each arguing vociferously that the other spellings would be confusing and detrimental.

ksluder · 2023-12-02T06:42:33.846Z

Nevin:

Judging by the discussion in this thread, it is abundantly clear to me that we do not have any sort of agreement in that regard.

As Ben stated subsequently:

Ben_Cohen:

It's important not to see lack of consensus alone as a reason to defer things.

wadetregaskis · 2023-12-02T06:50:15.719Z

Nevin:

That is the reality of how Swift evolution works: things can be added, but never taken away.

That's not actually accurate. The bar is certainly high for any kind of breaking change, whether it's technically a removal or not, but it can be (and historically has been) done.

e.g.:

Removing (essentially) @UIApplicationMain and @NSApplicationMain (SE-383: Deprecate @UIApplicationMain and @NSApplicationMain).
Removing a String initialiser (SE-405: String Initializers with Encoding Validation). It's being replaced with a functionally-equivalent one, and there's some renaming magic going on to minimise the disruption, but it's still technically a removal.
Removing the ability to conform other module's types to other module's protocols (SE-364: Warning for Retroactive Conformances of External Types).
Just today @hborla pitched removing -strict-concurrency=targeted.
And a whole bunch more historically (many of which can be easily found by searching for the word 'Remove' in SEP titles).

Also, technically Swift 6 removes the ability to do a bunch of concurrency-unsafe stuff.

I for one would like more breaking changes (in Swift major versions - 6, 7, …), because they often represent really valuable clean-ups and corrections (just look at some of the historical examples, and imagine if we'd kept all that stuff instead).

tera · 2023-12-02T08:58:50.763Z

Nevin:

things can be added, but never taken away.

You keep doing that and the vessel explodes.

tera · 2023-12-02T09:15:07.612Z

wadetregaskis:

It might be a challenge for the parser because of ambiguity with function calls…?

We were discussing the function call ambiguity aspect upthread: interestingly there's something in the compiler (if not in the grammar?) that prevents () or [] from being treated a function call / subscript if at least the opening ( or [ is not on the same line as the preceding expression, so that's no issue. We just haven't considered then the "compulsoriness" aspect (using () even if it's otherwise not needed to resolve the ambiguity, but as an "expression value" marker).

wadetregaskis:

I'm not sure it's intuitive, either. It looks like how ordered lists, or footnotes / references, are often written in text fields with limited formatting support, when used with integers.

Yes. It is meant to solve the issue often brought up against using the bare last expression - makes it easier to spot them.

BTW, if to use the last expression rule (bare or "dressed up") it is now obvious to me that it must not be done in the multi statement functions/closures (e.g. for the sake of consistency). The reasoning is the same as the reasoning not to use "return" to mean expression values. Whatever we choose, retuning a value from a function closure should be visually different to "expression statement" value (this is broken for the single-statement but let's not break it further in the multi-statement case). "Option 5" rules.

allevato · 2023-12-02T13:19:56.361Z

tera:

We were discussing the function call ambiguity aspect upthread: interestingly there's something in the compiler (if not in the grammar?) that prevents () or [] from being treated a function call / subscript if at least the opening ( or [ is not on the same line as the preceding expression, so that's no issue.

The grammar posted in TSPL is very much an approximation of the actual rules used by the parser. The parser itself explicitly requires that the ( of a function call must be on the same line as the callee: https://github.com/apple/swift-syntax/blob/6e708c4fa643057f41e3af7e6c0a2c405a487e56/Sources/SwiftParser/Expressions.swift#L727

      // If there is an expr-call-suffix, parse it and form a call.
      if let lparen = self.consume(if: TokenSpec(.leftParen, allowAtStartOfLine: false)) {

So the suggestion to require parens around a final expression wouldn't be ambiguous with function calls.

You know, I don't completely hate this idea. It doesn't seem worse to me than a new keyword and it takes advantage of existing syntax rules instead of having to invent new ones. The compiler will already parse it as a standalone expression without the ambiguities around implicit member references so I don't believe we'd be introducing any new ambiguities? But there might be some edge case I've missed.

And if the value being returned was a tuple, I think we could say that the parens around the tuple would be sufficient to satisfy the final expression; you wouldn't need to write ((x, y)).

The more I think about it, the more I like it, actually.

DanL · 2023-12-02T13:24:35.007Z

I don't remember anyone suggesting save:

x = if condition {
    doSomething()
    save 5
} else {
    save 0
}

Just wanted to add it to the list.

Caveat: it can also mean "except".

michelf · 2023-12-02T14:23:06.332Z

There's one thing about human language I'm wondering here. When we write return we say we're returning a value. But when we write then should we say… "thening" a value? The proposal text actually explain things using the verb "produce", but to me that illustrates a disconnect.

let value = do {
   print("producing 1 for value")
   then 1 // `do` will produce the value 1
}

Wouldn't it be clearer to use the same term in both places? This is what makes me think use / "using" is a better option:

let value = do {
   print("using 1 for value")
   use 1 // `do` will use the value 1
}

I like then, but I think it'd be better to use a verb.

Some other ideas…

I suppose we could also use produce, but for some reason I find this unappealing (perhaps it's too long?):

let value = do {
   print("producing 1 for value")
   produce 1 // `do` will produce the value 1
}

Or if we feel generous we could give a value:

let value = do {
   print("giving 1 to value")
   give 1 // `do` will give the value 1
}

I like this last one.

jberry · 2023-12-02T14:44:44.884Z

I haven’t weighed in on this pitch but have watched avidly from the sidelines as various arguments have been put forth and pondered excessively. I know this isn’t a vote, but I’ll offer my opinion.

I’m very excited to see this pitch. I very much hope it arrives in some form.

If it were a perfect world, I’d love to see the result come from the unadorned last line.

If issues with that cannot be surmounted, I’ll be very happy with then or use. return: no, please, never.

I don’t much like the idea of parens: that’s ugly, and I feel the prefix of a leading keyword more clearly marks the result. And converting from a single to multi-line expression block using parens would require tedious changes to both ends of the expression.

Geordie_J · 2023-12-02T16:04:04.238Z

Ben_Cohen:

It's important not to see lack of consensus alone as a reason to defer things.

Since this proposal seems likely to go forward in some way whether the community agrees on a way to do it or not, I would like to contribute what I consider to be the most preferable option for addressing the problem it aims to solve.

This exact problem has been solved before, e.g. in Rust, by implicitly "returning" the last expression in a block. With that in mind, I personally believe the preferable way to solve the problem is to finish the job started by SE-0255. That proposal mentions explicitly the main motivation for not always returning the last expression in a block: at the time, we didn't allow if/switch/do clauses as expressions (see Allow implicit return of the last expression even from bodies which consist of more than a single expression.).

That option is not open to us in Swift because conditionals are statements, not expressions in Swift. Changing Swift into an expression-oriented language would be a radical transformation to the language and is beyond the scope of this change.

Now we have the opposite problem: we do have if (etc) clauses as expressions, and it's weird.

So, instead of trying to bend Swift's syntax by adding more edge cases, I would much rather go back to Rust's existing precedent and enable implicit returns from the last line of any block. That would solve this problem at hand, and make Swift more internally consistent. For example, it has been an annoyance of mine since SE-0255 was introduced that adding e.g. a preceding print into a single-line implicit return causes it to no longer to return the value. Adding the implicit behaviour more generally would solve both issues.

wadetregaskis · 2023-12-02T16:11:11.064Z

michelf:

Wouldn't it be clearer to use the same term in both places? This is what makes me think use / "using" is a better option:
let value = do {
   print("using 1 for value")
   use 1 // `do` will use the value 1
}

But that perfectly highlights why use isn't great - the do expression isn't using the value 1, it's producing it (or "evaluating" to it, or "resulting" in it, or similar phrasing).

use, to me, throughout this discussion, has always read wrong because I find it mentally more related to inputs than outputs.

tera · 2023-12-02T16:32:18.562Z

allevato:

And if the value being returned was a tuple, I think we could say that the parens around the tuple would be sufficient to satisfy the final expression; you wouldn't need to write ((x, y)).

I'd still prefer the "((x, y))" form, just to not have an exception to the rule.

jberry:

I don’t much like the idea of parens: that’s ugly, and I feel the prefix of a leading keyword more clearly marks the result. And converting from a single to multi-line expression block using parens would require tedious changes to both ends of the expression.

Single-statement if expressions are relatively new thing... We could even deprecate the "bare" form of single statement expression as well and always require "dressed up" form (nudging users towards the dressed up form via deprecation warnings initially):

image1058×424 64 KB

wadetregaskis:

use, to me, throughout this discussion, has always read wrong because I find it mentally more related to inputs than outputs.

You are right... "produce" then?

michelf · 2023-12-02T16:51:10.137Z

wadetregaskis:

use, to me, throughout this discussion, has always read wrong because I find it mentally more related to inputs than outputs.

You have to reason it as "use this value in the outer context" and not as in "the inner construct (do, if, etc.) will use the value". This is indeed different from return "returning" a value in a function definition where the caller could be anyone, wheras when "using" a value you can readilly see where it goes. I have no problem seeing "use this piece to fill that hole" as something different from "return this piece to an unknown caller".

That said, my comparison with return was more about how "returning" mirrors the return you see in the code, while "producing" doesn't mirror then at all. I think use/"using" is more coherent than then/"producing" in this regard. But this coherence could also be acheived with produce/"producing" and give/"giving".

sspringer · 2023-12-02T20:28:53.906Z

michelf:

You have to reason it as "use this value in the outer context" and not as in "the inner construct (do, if, etc.) will use the value".

OK, this ambiguity might be an argument for the more abstract (?) “then”.

dannflor · 2023-12-02T22:26:45.665Z

Just want to add my +1 to implicitly returning the last expression. Seems like the cleanest way to resolve this and I enjoy using it in other langs.

DanL · 2023-12-03T12:47:05.631Z

Four examples that compare implicit vs use, save, or then:

if condition { value }
if condition { use value }
if condition { save value }
if condition { then value }

could be read as:

if true, (then) value
if true, (then) use value
if true, (then) save value
if true, (then) then value

or:

if true, consequence: value
if true, consequence: use value
if true, consequence: save value
if true, consequence: then value

These examples show do:

do { value }
do { use value }
do { save value }
do { then value }

and could be read as:

do value
do use value
do save value
do then value

Addendum regarding save:

We are, of course, saying that the value should be
saved for the assignment – or:

"the variable is assigned the value being saved"

Also: when we save something in an app, we hardly
think of "save" as meaning "with the exception of",
so I don't expect this to be a problem in real life.

tera · 2023-12-03T13:14:40.372Z

Good idea to remind about do. Also else.

if true then value else then value       // ?
do then value                            // ?
if true produce value else produce value // 👍
do produce value                         // 👍