# \[Pitch\] Last expression as return value

**URL:** <https://forums.swift.org/t/pitch-last-expression-as-return-value/76958>\
**Category:** Pitches\
**Created:** [January 2, 2025, 12:37am UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958 "2025-01-02T00:37:10Z")\
**Posts on this page:** 20\
**Page:** 8

<div class="post-metadata">

**Author:** ![DandyLyons](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dandylyons/32/14417_2.png) [@DandyLyons](https://forums.swift.org/u/DandyLyons)\
**Post date:** [January 5, 2025, 4:36am UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/147 "2025-01-05T04:36:28Z")

</div>

Sorry. I'm not quite sure what you mean. Are you referring to the first or second `if`?

---

<div class="post-metadata">

**Author:** ![georgeef](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/georgeef/32/38378_2.png) [@georgeef](https://forums.swift.org/u/georgeef)\
**Post date:** [January 5, 2025, 4:45am UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/148 "2025-01-05T04:45:54Z")

</div>

To the second, highlighted with red circle. The first is not an if expression.

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [January 5, 2025, 5:13am UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/149 "2025-01-05T05:13:38Z")

</div>

> [@ibex](#):
>
> Now, we have two kinds of `if` , two kinds of `switch`[...] I am just curious how much extra burden this proposed feature would put on the compiler.

The cost of distinguishing between these two kinds of `if` is truly negligible compared to the rest of the compiler (most of the work is early in the relatively low-cost part of the pipeline). And in particular, this extension of it doesn't increase the cost of them.

One of the explicit design goals of SE-0380 was to avoid creating a constraint system comprising the whole of the `if` expression. There is no backtracking from the second branch and back to the first. That's why this doesn't compile:

```swift
let maybeInt =
  if .random() {
    1
  } else {
    // error: 'nil' requires a contextual type
    nil
  }

```

You **must** provide enough type context to avoid needing to backtrack from the `nil` back to the `1` to determine that the type is actually `Int?`. (`let maybeInt: _? =` is enough to tell the first branch it's an `Int?`)

This is in contrast to the ternary operator where this compiles just fine:

```swift
let maybeInt = .random() ? 1 : nil 

```

but requires that backtracking.`1` would be an `Int` by default, then the `nil` invalidates this and requires re-evaluating the `1` as an `Int?`. This can be the source of lengthy compile times, especially when combined with other operators (using ternaries in more constrained environments, like in argument position, is generally much better).

Similarly, one of the (lesser) motivations of this pitch is to discourage the current slight nudge towards long compound expressions _in order_ to be able to stick within the single expression rule for closures, especially since closures themselves end up getting incorporated into bigger constraints, leading to longer compile times and enigmatic diagnostics when they have errors.

---

<div class="post-metadata">

**Author:** ![GuyB](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/guyb/32/12116_2.png) [@GuyB](https://forums.swift.org/u/GuyB)\
**Post date:** [January 5, 2025, 10:45am UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/150 "2025-01-05T10:45:30Z")

</div>

If anyone is counting let me add a strong -1.

As many have written the proposal will make reading and reasoning about SwiftUI or other result builder code significantly more difficult.

I am not against a keyword (or unambiguous operator) for a return within a multiline if/switch expression, but it should be explicitly spelt out e.g `returnvalue x` or `=> x`

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [January 5, 2025, 12:39pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/151 "2025-01-05T12:39:06Z")

</div>

> [@ben-cohen](#):
>
> One of the explicit design goals of SE-0380 was to avoid creating a constraint system comprising the whole of the `if` expression. There is no backtracking from the second branch and back to the first. That's why this doesn't compile:
> 
> ```swift
> let maybeInt =
> if .random() {
> 1
> } else {
> // error: 'nil' requires a contextual type
> nil
> }
> 
> ```
> 
> You **must** provide enough type context to avoid needing to backtrack from the `nil` back to the `1` to determine that the type is actually `Int?`. (`let maybeInt: _? =` is enough to tell the first branch it's an `Int?`)
> 
> This is in contrast to the ternary operator where this compiles just fine:
> 
> ```swift
> let maybeInt = .random() ? 1 : nil 
> 
> ```
> 
> but requires that backtracking.`1` would be an `Int` by default, then the `nil` invalidates this and requires re-evaluating the `1` as an `Int?`. This can be the source of lengthy compile times,

Strictly speaking this doesn't necessarily _require_ backtracking... The compiler could be constructed in a way to treat the first branch as "Int or optional int or something expressible by integer or floating point literal" and then reconcile what it found on both branches to get a more refined answer (be it "ok that's Optional Int" or "no, the two branches are non reconcilable" or "it's way too ambiguous, I need your help determining what you need".)

---

<div class="post-metadata">

**Author:** ![David\_Ungar2](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/david_ungar2/32/1511_2.png) [@David\_Ungar2](https://forums.swift.org/u/David_Ungar2)\
**Post date:** [January 5, 2025, 4:58pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/152 "2025-01-05T16:58:48Z")

</div>

When I designed the details of Self, the last expression in a method or control structure was always the returned value. But Self was designed to foster creativity, not to prevent bugs. Swift has different goals, but the relative priorities seem to be changing with time. Swift's old design to require the "return" keyword prioritizes clarity at the expense of ease of expression. This proposal reflects a shift in values. one I like, because MY programming is exploratory.

I don't like the effect of adding a new "if" form ("then") on the usability of the language. It burdens both learning and memory when reading code. If you know me, you know that I prioritize simplicity more heavily than having so many choices that you can always find one that does exactly what is needed and no more. Based on my own cognitive abilities, I would rather have to figure out which one of a small number of constructs to adapt, than to have to remember the exact forms of a multitude of constructs. But YMMV.

---

<div class="post-metadata">

**Author:** ![georgeef](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/georgeef/32/38378_2.png) [@georgeef](https://forums.swift.org/u/georgeef)\
**Post date:** [January 5, 2025, 7:48pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/153 "2025-01-05T19:48:26Z")

</div>

@David_Ungar2  
If you see the previous thread, the initial proposal was with a new keyword (`then`), and its title was saying nothing about "last expression". So I wouldn't blame the authors of this Pitch for a shift of values.

What you see in this Pitch is the result of many comments, which did not like the keyword `then`. I went quickly through the previous thread (which is quite long), and it is clear that `then`, `return`, `yield` were strongly rejected in most comments, but I'm not sure if there was a clear preference for no keyword at all.

Anyway, after some more effort from the side of authors, this Pitch gives now the opportunity to comment on if/switch/do expressions without keyword, and as a side-effect on the bigger topic of "last expression", which found its way in the new title.

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [January 5, 2025, 8:11pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/154 "2025-01-05T20:11:44Z")

</div>

> [@tera](#):
>
> Strictly speaking this doesn't necessarily _require_ backtracking...

Your "many worlds hypothesis" scheme works with a limited set of possible things to carry forward, but that only works with simple future possibilities like "this might have been optional" or "this might have been an integer or float literal". But consider this example:

```swift
let a = [1,2,3]
let x = .random() ? a.lazy.filter { $0 < 1 } : a

```

The backtracking involved here is very subtle. Initially the value for the first branch is a `LazyFilterSequence<[Int]>`. Then in the second branch, the overall type is determined to be `[Int]`. So the first branch is re-evaluated. There happens to be a less-favored overload of `filter` on `LazySequence<[Int]>` that produces an `[Int]` – the regular `Sequence.filter(_:)->[Element]`. So it then decides to call that instead.

`if` expressions veto this kind of thing, by requiring that all the branches can be resolved independently. The only way to make the above compile with an `if` expression is to be more explicit:

```swift
let y = if .random() { a.lazy.filter { $0 < 1} as [Int] } else { a }

```

Which is a good thing, because it also makes clear to the author that their attempt to do something lazily was getting thwarted, unlike the ternary example where it undoes the laziness silently.

---

<div class="post-metadata">

**Author:** ![DandyLyons](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dandylyons/32/14417_2.png) [@DandyLyons](https://forums.swift.org/u/DandyLyons)\
**Post date:** [January 5, 2025, 9:43pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/156 "2025-01-05T21:43:51Z")

</div>

Multiple people (including me) in this thread have raised the question of how this proposal interacts with Result Builders. If I'm not mistaken, I don't believe these questions have been fully addressed within this thread, however, it looks like they have already been addressed in [SE-0380](https://github.com/swiftlang/swift-evolution/blob/80c3616bb23e7bf751f886aaf178acb3df09abe5/proposals/0380-if-switch-expressions.md?plain=1#L233):

> **The expression is not part of a result builder expression**
> 
> `if` and `switch` statements are already expressions when used in the context of a result builder, via the `buildEither` function. This proposal does not change this feature.
> 
> The variable declaration form of an `if` will be allowed in result builders.

If I understand this correctly, it's saying that already, today, if an `if` or `switch` is used in the context of a Result Builder, then the Result Builder will take precedence, so the `buildEither` function will be used, and the in-place `if`/`switch` expression will not be used. (That is as long as the user doesn't explicitly opt-in to `if` expression syntax by writing something like:

```swift
let foo = if a { "A" } else { "B" }

```

So it seems whatever ambiguity there could be with Result Builders, is leftover ambiguity that already exists today (since Result Builders can be implicitly applied already, like on `body` in the `View` protocol). This proposal doesn't seem to increase ambiguity (at least when it comes to code that a human could interpret as either an if expression or a `buildEither`).

@localhost shared [this example](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/19):

```swift
var body: some View {
    Text("Foo")
    Text("Bar")
}

```

which is currently interpreted as something like:

```swift
var body: some View {
    Group {
        Text("Foo")
        Text("Bar")
    }
}
// `body` evaluates to something like TupleView<Text, Text>

```

Presumably, after this proposal, it would be interpreted as this:

```swift
var body: some View {
    Text("Foo") // ⚠️ Unused expression.
    return Text("Bar") // this return is implicit
}
// `body` evaluates to just Text

```

The warning would immediately draw attention to the cause of the problem, but this would be a breaking change in many code bases.

It seems worth considering if the "last expression as return value" rule should **not apply** within Result Builders (just like `if`/`switch` expressions already don't apply within Result Builders).

(This behavior may already be intended, but I don't think I saw it mentioned explicitly in the proposal.)

---

<div class="post-metadata">

**Author:** ![georgeef](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/georgeef/32/38378_2.png) [@georgeef](https://forums.swift.org/u/georgeef)\
**Post date:** [January 5, 2025, 9:59pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/157 "2025-01-05T21:59:09Z")

</div>

The code with `Group` is equally confusing.

```swift
var body: some View {
    Group {
        Text("Foo")
        Text("Bar")
    }
}

```

Even if the compiler does not inject a `return` before the last `Text`, to a human reader it looks like the second `Text` is the last expression in its closure, so it is the return value. And in case there is some lengthy code between the two `Text`, it becomes even more confusing.

---

<div class="post-metadata">

**Author:** ![georgeef](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/georgeef/32/38378_2.png) [@georgeef](https://forums.swift.org/u/georgeef)\
**Post date:** [January 5, 2025, 10:14pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/158 "2025-01-05T22:14:20Z")

</div>

The over-reuse of the same keywords and symbols for multiple purposes, which becomes more and more common in Swift, eventually collapses. I think this proposal is at the edge of such a collapse. Maybe the compiler can still deal with it, and maybe in an efficient way, but for human readers it starts becoming ambiguous.

I hope in the future we don't need to compete with a computer (compiler) in solving difficult puzzles. We can resign already, as chess players did years ago.

---

<div class="post-metadata">

**Author:** ![andyj-at-aspin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andyj-at-aspin/32/18552_2.png) [@andyj-at-aspin](https://forums.swift.org/u/andyj-at-aspin)\
**Post date:** [January 6, 2025, 11:36am UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/159 "2025-01-06T11:36:44Z")

</div>

+1.

It's handy for short use cases with small blocks that just introduce chatter where the addition of intermediate values (for examination whilst debugging) or logging required the refactoring of existing implicitly returned values.

The _ **return** _ keyword _isn't going away_ so keep using it everywhere in your future coding - and of course, your existing code bases - if you don't like the feature.

_Bad_ code can always be written, and newcomers to the language might experience short confusion _when coming from other languages_ - but it would be a terrible attitude to write closures extending more than maybe a quarter/half a page of screen and just ending them with implicit returns with an implied _arm cross and "just deal with it"_ attitude.

---

<div class="post-metadata">

**Author:** ![stackotter](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stackotter/32/20670_2.png) [@stackotter](https://forums.swift.org/u/stackotter)\
**Post date:** [January 6, 2025, 2:37pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/160 "2025-01-06T14:37:56Z")

</div>

> [@Paul\_Cantrell](#):
>
> Most of the -1 responses are vague hand-waving objections about readability. Most of those amount to anything other than “It feels unfamiliar to _me_,” which I just find completely uncompelling. I’ve looked at the supposed examples of resulting unreadability, and just don’t find them unreadable. Sorry.
> 
> Familiarity bias rules all.

A big +1 to this sentiment from me too. I was already planning a similar response while catching up on this thread (before reaching that post).

There are many existing features in the language that are nice to have but would conceivably have had similar arguments made against them if they were pitched today.

Consider `$n` closure parameters (e.g. `{ print($0) }`). "If you have a large closure it's hard to know how many parameters it takes" would be a likely argument to come up in a hypothetical pitch thread. In practice, developers generally only use that feature in non-confusing scenarios (short closures in this case), because most developers tend to naturally limit how confusing their code is. And if not, they can already write exceedingly confusing code in Swift.

I write quite a lot of Rust code and have always found `if/switch` expressions easy to skim read from the start. Of course, there are always confusing examples but in practice the return values generally stand out.

* * *

> [@jpmhouston](#):
>
> However we shouldn't encourage footguns. A `return foo` at the end of a function is unambiguous, isn't burdensome, is good. I think to generalize this solution, extending the new rule to any and all functions, is an overstep and a mistake.

I'm completely fine with this concession if it's what gets this proposal through.

As you hint at, bare last expressions for functions and closures are purely a matter of taste, whereas for `if/switch` expressions the absence of bare last expressions as a feature (or any of the similar discussed alternatives) is a pretty big gap in Swift's expressivity.

Imo `if/switch` expressions have limited use in their current form (despite being very useful when they are able to be used). And either way (with or without function/closure support) this proposal will bring `if/switch` expressions from a half-baked feature to the feature that people were actually hoping for when the original `if/switch` expressions proposal was in discussion.

---

<div class="post-metadata">

**Author:** ![Andropov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andropov/32/35955_2.png) [@Andropov](https://forums.swift.org/u/Andropov)\
**Post date:** [January 6, 2025, 3:32pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/161 "2025-01-06T15:32:23Z")

</div>

Even though I have run into the issue this pitch addresses multiple times, I think the readability concerns far outweigh the benefits here. The motivating issue is just a minor nuisance, IMHO hardly enough justification by itself to introduce such a significant change to Swift’s syntax.

On the topic of readability, which I think is the biggest concern: a key aspect of what makes code readable for me is the ability to quickly locate all the possible return values of a function, without mentally parsing the entire control flow of the code. Currently this is very easy: either all return values have `return` before them _or_ the function is trivial enough that it's obvious by inspection. I think it was reasonable to allow implicit returns where the intent is obvious (such as in one line expressions), but this pitch seems to allow writing large and fairly complex functions where the control flow is not trivial at all yet values are returned implicitly as if it were obvious.

This could be mitigated by the IDE (as discussed above), but code is sometimes read in plain text (or with lightweight syntax highlighting). Plus it feels like a major step back to need to rely on tooling when syntax alone has been able to convey this information clearly until now.

I think this will be particularly confusing when adding function calls to the mix, because the callee’s signature is not visible at the call site, so it may take a couple looks to realize what is and isn’t a return value:

```swift
func getProfileImage(id: UUID) async -> Image {
    // …
    if checkForAccess(id: id) {
        let image = if let cachedImage {
            cachedImage
        } else {
            await downloadImage(id: id)
        }
        switch size {
        case .thumbnail:
            image.resized(to: .small)
        case .detail:
            image
        }
    } else {
        onUnauthorized() // <- This returns an Image, but it’s easy to miss.
    }
}

```

Compared to:

```swift
func getProfileImage(id: UUID) async -> Image {
    // …
    if checkForAccess(id: id) {
        let image = if let cachedImage {
            cachedImage
        } else {
            await downloadImage(id: id)
        }
        switch size {
        case .thumbnail:
            return image.resized(to: .small)
        case .detail:
            return image
        }
    } else {
        return onUnauthorized()
    }
}

```

Granted, there’s a familiarity bias here and it’d get easier over time, but even for new developers this would be harder to learn than the explicit keyword. And even for experienced devs, it feels like it’d be much easier for a mistake to go unnoticed.

On the topic of _consistency_: I feel like this is just “moving the line” of which situations are considered obvious enough for implicit returns to be allowed, not necessarily making the language more consistent. To this point, I was quite surprised by this pitch explicitly mentioning that `guard` statements wouldn’t allow implicit returns:

> [@ben-cohen](#):
>
> Guard statements can contain more than just returns – they can continue/break, abort, or throw, and so an explicit return is still required.

Isn’t this even more true for functions? It feels odd (and inconsistent) to forbid this:

```swift
func divide(by denom: Double) -> Double {
    guard denom != 0 else { .nan }
    // …
}

```

For not being clear enough yet allow massive functions with nested control flow statements to return implicitly.

* * *

The argument _just use a linter if your preferred code style is explicit `return`s_ or _just don’t use the feature if you don’t like it_ are missing the point. This pitch, if implemented, would change how _everyone_ writes Swift code, _everywhere_, for better or worse. You can set up your linter to fight the language if you so wish, but everywhere else (Stack Overflow answers, Swift Forums posts, GitHub repositories of open source projects...) you'd need to reason about any code being displayed knowing how implicit return works. At that point, it's always more productive to accept the new status quo of the language and move on than to try self-impose a dialect on the few projects you have the power to do so.

Similarly, just because no language can prevent bad code from being written, I don’t think we should disregard concerns about a change making bad code significantly easier to write (or, as in this case, opening the door to a new flavor of bad code that wasn’t possible before). It may be worth the trade off, but it shouldn’t be left out of the discussion.

---

<div class="post-metadata">

**Author:** ![crontab](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/crontab/32/7374_2.png) [@crontab](https://forums.swift.org/u/crontab)\
**Post date:** [January 6, 2025, 4:34pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/162 "2025-01-06T16:34:21Z")

</div>

> [@Paul\_Cantrell](#):
>
> Most of the -1 responses are vague hand-waving objections about readability. Most of those amount to anything other than “It feels unfamiliar to _me_,” which I just find completely uncompelling.

Honestly I find it a bit insulting that the counter arguments in this thread are being called "vague hand-waving objections". ~~You probably didn't understand them very well.~~ Apologies for the last sentence, I do realize it was also rude.

---

<div class="post-metadata">

**Author:** ![georgeef](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/georgeef/32/38378_2.png) [@georgeef](https://forums.swift.org/u/georgeef)\
**Post date:** [January 6, 2025, 4:52pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/163 "2025-01-06T16:52:57Z")

</div>

The argument "don't use a feature if you don't like it" is valid for an additive feature, which adds something new (with new syntax or keyword), not for a subtractive feature, which removes something already existing and heavily used. The return from a function is a must-have feature, you cannot just ignore it if you don't like its syntax.

And in general it is valid for small things, not for critical things. With some exaggeration, imagine that you go to a hotel and they tell you: there is a bomb in your room which is activated with a code, but if you don't like this feature just don't use it.

---

<div class="post-metadata">

**Author:** ![andyj-at-aspin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andyj-at-aspin/32/18552_2.png) [@andyj-at-aspin](https://forums.swift.org/u/andyj-at-aspin)\
**Post date:** [January 6, 2025, 5:09pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/164 "2025-01-06T17:09:55Z")

</div>

But by definition, you're already conditioned to write return at the end of every closure that does so, so _just keep doing it_. Do you expect anyone to be relying on the compiler reminding them that they've forgotten to return a value when one was expected?

---

<div class="post-metadata">

**Author:** ![georgeef](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/georgeef/32/38378_2.png) [@georgeef](https://forums.swift.org/u/georgeef)\
**Post date:** [January 6, 2025, 5:30pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/165 "2025-01-06T17:30:41Z")

</div>

As mentioned by @Andropov above, it is not only how I want to write my code. I write some code from scratch, I copy-paste some other code, and I read a lot more code written by others. So it is not a freedom to use `return`, it is an obligation to accept and get used to the absence of `return`.

Also, as said above, the first example in this proposal doesn't have a `return` in the last branch, and it does not accept a `return` or any other keyword as optional.

---

<div class="post-metadata">

**Author:** ![sspringer](https://avatars.discourse-cdn.com/v4/letter/s/e9c0ed/32.png) [@sspringer](https://forums.swift.org/u/sspringer)\
**Post date:** [January 6, 2025, 5:31pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/166 "2025-01-06T17:31:09Z")

</div>

> [@crontab](#):
>
> Honestly I find it a bit insulting that the counter arguments in this thread are being called "vague hand-waving objections".

I think anyone here respects the others‘ opinions, sometimes the formulations should be more diplomatic so to speak. (Some seemed to be offended by my own last comment above, I should have expressed it differently, sorry.)

A hopefully more “diplomatic” formulation might be that the author of this comment thinks that one might to easily object a new idea on first impression and that the author rates the “getting used to” higher than other people might do. I think this is a valid opinion that does not invalidate the objections formulated by others.

---

<div class="post-metadata">

**Author:** ![carlynorama](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/carlynorama/32/27072_2.png) [@carlynorama](https://forums.swift.org/u/carlynorama)\
**Post date:** [January 6, 2025, 5:36pm UTC](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958/167 "2025-01-06T17:36:18Z")

</div>

Indeed. "I reject your biases in favor of my own because mine are clearly logically superior because they are mine" is equally "uncompelling". Dismissive rhetoric generally is about squishing the other people into submission to make them go away and "win" that way. (note Ben Cohen has NOT done any of that. He's doing really well. Additionally people who just say it's what they want with enthusiasm, also great! Love the joy.)

Out of curiosity, does Swift/Apple even have a budget line item for Human Factors testing of proposed changes? (I mean real broad recruitment PhD designed Human Factors testing.) I think I brought this up before.

Personal opinions about what will or will not confuse certain groups of users are just opinions. Until they are _tested_.

I have objections beyond readability but I think a lot of discussions on Swift proposals come down to a bunch of developers having strong opinions about what they THINK will or will not matter to different developer groups. Great. That is useful and not to be dismissed anecdotal data. Thank you for bothering to engage with the community.

I do think it would be nice if the LSG got additional input, actually collected data. Give developers of varying levels of experience actual tasks to complete with different features enabled. Record how much time it takes / what their confidence rating is / etc. Consider it [an option 4](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/287) to add to the arsenal.

Human factors testing is not the be all end all. It's not always great at creating a new feature. But it can cut through _feelings_ about what will or will not happen when certain significant changes are made. Frequently the results are surprising to all parties.

Recruitment is incredibly expensive, so batch testing proposals would likely have to be done.

I don't mind reading about other people's feeling on a topic. It's informative. But then people... go off the rails. It'd be nice to have "Thanks for your input. We'll for test that" to keep things on the road.

[Previous page](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958.md?page=7)

[Next page](https://forums.swift.org/t/pitch-last-expression-as-return-value/76958.md?page=9)