ASSERT vs. [end]able FAIL

[hostilefork]

@hostilefork

If you think about it, a FAIL with no arguments doesn't have a lot of options for what to do besides report an error. So why not make it <end>-able (the same way HELP can accept either no arguments or one argument), and assume that a FAIL with no arguments is just a way of saying "fail here"?

There are other applications for this:

switch type of x [
    integer! [...]
    text! [...]
    fail
]

That's more succinct than switch ... [...] else [fail].

This five-year-old idea has been put to good use and feels like it has proven its mettle.

But reviewing old posts I realized that it does theoretically suffer from the line continuation arity bug.

This is to say you might have some code like:

 blah blah blah
 more blah blah

And decide you're going to just throw a FAIL in the middle:

 blah blah blah
 fail
 more blah blah

Because you're used to the idea that FAIL can be used with no arguments. Yet the more blah blah will be picked up as an argument to fail, as if you'd written:

 blah blah blah
 fail (more blah blah)

The consequences aren't quite as dire as when this was being used with the likes of RETURN...because FAIL generally stops execution anyway. But it could lead to unexpected results.

I just wanted to reiterate that <end>-able constructs...cool as they seem...have this blind spot when code is broken across lines.