Allow Expression[] or return

[LenkyDev]

Expression[] or return triggers the following error Precedence doesn't allow "return" following "or"(3100).

This is common in production code and a recurring pattern for safe access or bail out.

This a separate issues from "allow return in decides context" as that is a broader topic which implicates some issues with lenient evaluation, wherein this does not.

---

Mayapple

[KnightBreaker]

This issue should be merged with the lack of guard.

The following pattern emerges quite often in some code bases:

GValue1 := if (UValue1 := Value1?) {
  UValue1
} else {
  return
}
GValue2 := if (UValue2 := Value2?) {
  UValue2
} else {
  return
}
GValue3 := if (UValue3 := Value3?) {
  UValue3
} else {
  return
}

A borrowed guard else syntax from Swift could help here. It would not just invert the if, but also unfold its then block into the remaining scope.

guard:
  UValue1 := Value1?
  DoSomeCheck[]
  UValue2 := Value2?
  # peform other complex operations like in `if (...)`
  UValue3 := Value3?
else {
  # handle extra side effects here
  return # must return from here
}

# use UValue1 UValue2 UValue3 here

---

Comparing to or return a guard can handle and unfold multiple expressions and does not require repeated or return usage. Additionally it permits for more complex operations within the else block prior to return.

[sprintermax]

Not only for returns, but basically any control flow keyword, even unreleased ones such as continue

Note that there is already a forum post with this, marked as "To Do":
https://forums.unrealengine.com/t/verse-wrong-error-and-warning-message-about-return-following-or/2656462/4

[sprintermax]

Also, I think this can be related to guards since is a lot used together:

The "let" keyword should allow non-assignment expressions:

Currently let blocks requires everything being inside an assignment (ex. Thing := <expression>) even if we don't need to use the Thing.
This is a "virtual" limitation (probably a bug?) that should not exist here. Currently we do _UNUSED := <expression> (I use _Guard prefix) as workarounds everywhere to circumvent this bug

Here are some real examples from some of my libraries, showing the weird current behavior, and the "workaround" to bypass it: