<div dir="ltr"><div dir="ltr">Den tors 21 jan. 2021 kl 18:21 skrev Nicolas Martyanoff <<a href="mailto:khaelin@gmail.com">khaelin@gmail.com</a>>:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
While I agree that some of the examples you give are indeed confusing, why<br>
would a warning flag not be good enough ? It would have multiple advantages:<br>
<br>
- Anyone would be able to either warn or totally reject (with<br>
  warnings_as_errors) these kinds of construction.<br>
- Anyone who does not care would be able to totally ignore it (and please do<br>
  not tell me that this new operator/annotation would be optional, there is no<br>
  way it would not be become mandatory at some point).<br>
- This would have no effect on existing codebases, therefore removing any<br>
  migration cost. I cannot even begin to explain how bad of an idea it would<br>
  be to force every Erlang developer all other the world to patch all their<br>
  projects because something that worked perfectly before now requires a<br>
  cryptic annotation.<br></blockquote><div><br></div><div>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. In practice then, it makes no difference if the patching consists of adding a ^, or inventing a new temp variable and adding a guard test, except that the latter is much harder to automate.</div><div><br></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 not affect the language itself in any way, sidestepping any<br>
  discussion about the syntax itself.<br></blockquote><div><br></div><div>As discussed in other replies, we could do it this way - if the ^-notation doesn't merit including in its own right as a way to write clear and concise patterns. But I'm arguing that these examples are better with ^ than with guards.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now you could argue that you wish to be able to use these kinds of<br>
constructions on occasion, but then surely you would agree that checking<br>
equality in a guard is far more explicit and therefore more readable.<br></blockquote><div><br></div><div>This is where I don't agree - especially after looking at the experimental diff and thinking "how readable would all this be with plain guards instead?".</div><div><br></div><div>When you read something like</div><div><br></div><div><div>    receive<br>        {ssh_cm, SSH1, {open, Chn1, RemoteChn, {session}}} when SSH1 =:= SSH, Chn1 =:= Chn -><br></div><div></div></div><div><br></div><div>you both need to look at the pattern and note which variables are in which positions, as well as read and understand all the guard expressions, before you can say "ah, it only matches when this position is the already existing SSH and that position is the existing Chn binding. This is tolerable, but not great.</div><div><br></div><div>When you read the same code written with ^-notation, you can see what it's doing at only a glance:</div><div><br></div><div>    receive<br>        {ssh_cm, ^SSH, {open, ^Chn, RemoteChn, {session}}} -><br><br>and you don't need to think about whether those extra variables have further uses, or if the guards were correctly written.</div><div><br></div><div>    /Richard</div><div><br></div></div></div>