[Feature request] Inline assertions whose success/failure result can be used in expressions

[Rangi42]

Spinoff from the comments of #201. I've encountered a use case for this twice recently:

• In pokered, we twice want to do assert COND, "message" but then use COND in some further logic. Having to define a temp variable would be more trouble than it's worth vs just repeating the COND expression.
• In pokecrystal, we repeat this pattern for getting an unlabeled SRAM location from its labeled WRAM counterpart:

  ld hl, sPlayerData + (wEventFlags - wPlayerData)
  ld hl, sPlayerData + (wHallOfFameCount - wPlayerData)
  ld hl, sPlayerData + (wPlayerID - wPlayerData)
  ; etc

  What I'd rather do:

  def Saved(label) = sPlayerData + (label - wPlayerData)  ; user-defined function
  ld hl, Saved(wEventFlags)
  ld hl, Saved(wHallOfFameCount)
  ld hl, Saved(wPlayerID)
  ; etc

  However, that would be unsafe to use without a precondition of label >= wPlayerData && label < wPlayerDataEnd. User-defined functions are single expressions, so we would need an expression assert:

  def Saved(label) = \  ; user-defined function
    assert(label >= wPlayerData && label < wPlayerDataEnd, "Cannot save label") * \
    sPlayerData + (label - wPlayerData)
  ld hl, Saved(wEventFlags)
  ld hl, Saved(wHallOfFameCount)
  ld hl, Saved(wPlayerID)
  ; etc

We could probably also handle three-arg assert(warn/fail/fatal, cond, msg).

[ISSOtm]

I remain of the opinion that assert()s should not be expressions, because they don't have a value. The operator between the assertion and the rest of the expression is supposed to be irrelevant, but that's not necessarily true depending on the “placeholder” value of an assert() (if it's 0, then the OP's third code block will break).

There is value in an assert that evaluates to its controlling expression, à la complex pointer expression ? : &dummy in (GNU) C; however, there are also use cases for wanting an assertion without using its condition (e.g. assert(THING, "awawawaaaaaaa") * STUFF / THING, which yes can be written as assert(THING != 0) to avoid the bug, but those two are equivalent with directive assert so that'd be a footgun IMO).

I'm not sure what syntax to use for same-line ret-val-ignored assertions. Perhaps we'd want to make them not part of general expression syntax, and instead add special syntax for asserting preconditions in functions?

Alternatively, we could try repurposing some operator, like assert(THING, "awawawaaaaaaa") :: STUFF / THING, which is currently unambiguous grammar-wise, but I'm not feeling entirely confident about.

[Rangi42]

Never mind then.

[ISSOtm]

Okay, the first line of my comment was written before I thought about the issue further, and thus expresses a different line of thought than what I have now. So, let me attempt to rephrase:

I believe “pass-through” assertions within expressions are useful, since they do have a value; however, we may want to refine the concept a bit, to allow checking for something different, such as assert(<complex expression>, result % 2 == 0, "Stuff must be aligned") >> 1. Additionally, I think there is a use case for assertions whose result is discarded without having to resort to arcane/unintuitive operator usage, like assert(...) * 0 + <rest>.

I would like to reopen the issue, as I am not against the concept, and thus believe the closure to have been made in error.

[Rangi42]

Alright. I'd be fine with assert(cond, msg) evaluating to cond instead of !!cond.