<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 12, 2018 at 4:30 AM Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 09/10/2018 04:37 PM, Fred Hebert wrote:<br>
> If a single |begin ... end| block calls to these as the potential return <br>
> value of a function, the caller now has to have the following type <br>
> specification:<br>
> <br>
> |-spec caller() -> ok | {ok, term()} | {ok, term(), [warning()]} | <br>
> {error, term()} | {error, term(), term()}. |<br>
<br>
Isn't that incorrect? There's no reason the spec for caller() would have <br>
all 3 'ok' in its type since the resulting type would be either the <br>
error tuples OR the result of the last expression in the begin..end <br>
block (which may or may not be the left hand side of a <~ expression).<br>
<br>
So the spec for caller() would be:<br>
<br>
-spec caller() -> OK | {error, term()} | {error, term(), term()}.<br></blockquote><div><br></div><div>You are right, yes,<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Somehow I do not see this as being a big problem, at least as far as <br>
specs go. There's very little code that's larger than a 3-tuple for <br>
error tuples, and even 3-tuples are not that common.<br>
<br></blockquote><div><br></div><div>I did a quick check in the OTP repo.</div><div><br></div><div>For all error tuples:<br></div><div>$ ack -r '{error,' | wc -l<br>19725</div><div><br></div>I've grabbed a list of the files, split them into tokens with erl_parse, and then counted the number of commas/tuples to account for nesting and what I've found is something like this:</div><div class="gmail_quote"><br></div>#{2 => 16848,3 => 2166,4 => 155,5 => 90,6 => 2}<div class="gmail_quote"><br></div><div class="gmail_quote">Where each key is the number of terms in the tuple. Here's the same version as percentages:</div><div class="gmail_quote"><br></div><div class="gmail_quote">#{2 => 85.414,<br>  3 => 10.981,</div><div class="gmail_quote">  4 => 0.786,<br>  5 => 0.456,</div><div class="gmail_quote">  6 => 0.010}<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">It's not fully accurate, but it's probably representative of things, or in the right order of magnitude.<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This would basically correspond to a case block where instead of <br>
matching on "{error, _}" and returning that, you would match on "Error <br>
when element(1, Error) =:= error".<br>
<br>
Doesn't sound like this would have negative performance implications <br>
either, it may actually be faster since you don't need to check the <br>
tuple size.<br>
<br>
This can be allowed regardless of the unwrapping done on ok tuples and <br>
whatever limitations they may have.<br>
<br></blockquote><div><br></div><div>I don't have a strong opposition to this, especially if the unwrapping remains in place. At this point I think this is a question where I'd like to follow the OTP technical committee's preferences to get this feature going. I see value in standardizing error tuples, but the gained flexibility on error handling is not necessarily bad either (I'd really like uniformity though!), at least not enough to make me think it would be a mistake to do it. Whatever they prefer I'd be fine going with, I think.<br></div><div><br></div><div>It shouldn't lead to significant return value bloating at this point, and I've made use of error triples in the past for some annotations. Though if everyone headed towards 2-tuples for errors, I'd bet a nested tuple would risk becoming a bit more common for annotations and structural data.<br></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div>