On 21/01/2021 20:55, Richard Carlsson wrote:
Den tors 21 jan. 2021 kl 18:21 skrev Nicolas Martyanoff
<[email protected] <mailto:[email protected]>>:
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
advantages:
- 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.
--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
