[eeps] EEP 049: Value-Based Error Handling Mechanisms

[Fred Hebert]

On Fri, Oct 23, 2020 at 7:32 AM Björn Gustavsson <bjorn@REDACTED> wrote:

>
> We have handled the addition of new keywords in the past by having an
> option to disable them (keeping the new keywords as atoms). That we
> will allow the compilation of old code that uses the keyword as an
> atom. (We did that when we introduced try/catch.)
>

Sounds good to me.

I'd be fine speccing the addition of an 'else-style' keyword for begin ...
end. A funny thing to consider is that if we add 'else', people will be
really confused about why begin ... end has it but not if ... end. I figure
this is out of scope for this specific RFC, but worth pointing out
regardless.

I'll try to find slack time over the next week or two to edit EEP-49,
including the quoted workaround and possibly some additional research. But
to do a tl:dr;, this is heading for:

   - begin ... end with an optional begin ... else ... end variant
   - The "unwrap expression" is replaced by a "match or return" mechanism.
   - since there is no longer any unwrapping we can switch form <~ to <- as
   an operator and keep rather familiar semantics
   - the else keyword (or anything else that takes its place) would require
   compiler options that specify using it as an atom to allow compilation of
   older modules which do not use the construct and rely on the same keyword.

I'm gonna have to look into whether this can still be safely emulated with
simple case expression being shifted around or if it requires fancier a
lower-level rewrite. I doubt it can be that easy to do because we have to
intersperse non-conditional code in there and a goto-like mechanism could
make more sense (an option would also be to use a ref with a throw/catch,
but I'd rather avoid the cost of generating a ref per block of
conditionals). Anyway, while I look into this, that'll give time to get
more potential feedback or information from the OTP team, which Kenneth has
hinted at.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20201023/a92a3904/attachment.htm>