New EEP draft: Pinning operator ^ in patterns
Thu Jan 21 23:55:04 CET 2021
On 21/01/2021 20:55, Richard Carlsson wrote:
> Den tors 21 jan. 2021 kl 18:21 skrev Nicolas Martyanoff
> <khaelin@REDACTED <mailto:khaelin@REDACTED>>:
> While I agree that some of the examples you give are indeed
> confusing, why
> would a warning flag not be good enough ? It would have multiple
> - Anyone would be able to either warn or totally reject (with
> warnings_as_errors) these kinds of construction.
> - Anyone who does not care would be able to totally ignore it (and
> please do
> not tell me that this new operator/annotation would be optional,
> there is no
> way it would not be become mandatory at some point).
> - This would have no effect on existing codebases, therefore
> removing any
> migration cost. I cannot even begin to explain how bad of an idea
> it would
> be to force every Erlang developer all other the world to patch
> all their
> projects because something that worked perfectly before now
> requires a
> cryptic annotation.
> As you yourself note, the warning is likely to eventually be made the
> default (if generally accepted), and this means for most code bases
> these days that they'll be patching their code anyway, just in order to
> compile cleanly with default flags - something most projects want.
If the warning gets enabled by default I think I would just disable the
warning in my own projects. I agree that ^ can make some code more
obvious, but I definitely don't want this to be enforced everywhere.
Socket messages, monitors and other message refs, tests and other
similar places would not gain in readability in my opinion. The places
where readability increases are those where matching is not expected,
like most of your examples seem to be. Though in some of those cases a
comment would be much better.
You say ^ indicates that the match is intentional, and in a perfect
world perhaps that's true, but in the real world you'll also end up with
misplaced ^ that should not be matches at all, as some of your examples
show. So while you do increase the confidence that the match was
intended, it's not necessarily the case. Ultimately all it says is "this
variable is already bound".
As a result, the ^ alone does not convey much information. You don't
know why the dets:check_file_header/2 function is called twice, a
comment would work out much better. (A comment explaining why one call
is protected in a try..catch and one isn't would be great as well.)
Maybe parse_term/3 really does have to return the same "D" value, but ^
only tells you it's expecting the same value, it doesn't tell you why.
And so on.
There are a few good catches, but this only comforts me into thinking
this belongs more in tooling than in the language. That said, the
warning could be used as a tool on its own, just making a special
non-test build would print all the warnings which can be quickly
checked, similar to +bin_opt_info. Maybe enable it on a per module basis.
More information about the erlang-questions