<div dir="ltr">On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith <span dir="ltr"><<a href="mailto:zenparsing@gmail.com" target="_blank">zenparsing@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>And for the strict match one could introduce match(...) function which already would throw providing exactly matching procedure first, and then destructuring as a consequence.</div>
</blockquote><div><br></div></div><div>Do you not think that it would be awkward to have the exact same pattern syntax for these two cases (matching and destructuring), but with different semantics?</div><span class="HOEnZb"><font color="#888888"><div>
<br></div></font></span></div></div></div></blockquote><div><br><br></div><div>Yes, I don't think so. Also, this exact (or strict, or refutable if you will) matching I'm proposing as addition. And for this it's good to have a very good practical use-case and a reason. Do you know such practical use-cases today when people need strict match with throwing? How widely they are used?<br>
<br></div><div>tl;dr:<br><br></div><div>In immutable state languages, there is no assignment operation, there is only "binding-and-matching" operation. Which means an unbound variable can be bound once, and all other "assignment" operations already pattern matching operations -- they can only check whether the LHS matches to what is on RHS.<br>
<br></div><div>X = 10; // initial binding<br><br></div><div>X = 20; // throw, doesn't match<br></div><div>X = 10; // OK, match<br><br></div><div>Y = 10;<br></div><div>X = Y; // OK, match<br><br></div><div>Z = [1, 2, 3];<br>
</div><div>Z = [1, 2, 3]; // OK, match<br></div><div>[A, B, C] = Z; // OK, match. See -- the matching goes first, and the destructuring is just a consequence.<br></div><div>[A, _, C] = Z; // OK, match, skipping second element<br>
</div><div>[A, B] = Z; // throw, doesn't match<br><br></div><div>In JS, there is mutation and assignment. And pattern matching here is secondary. Initially exactly the destructuring plays main role here. And again, for the current foo.nonExisting being undefined use-case is also leans towards not throwing.<br>
<br></div><div>The non-strict destructuring use-case is though can be wide spread, especially with `config` parameters:<br><br></div><div>function init({ip, coords: [x, y]}) { ... }<br><br></div><div>The match function can go either on RHS (which probably better, but I'm not sure at implementation), or LHS:<br>
<br></div><div>switch (match(foo)) {<br></div><div>  case {x, y}:<br></div><div>  case [a,b ,c]<br></div><div>}<br><br></div><div>The match(...) function may just set [[StrictMatch]] temp prop on the object and then matching goes with the strict (I wouldn't do it using "use strict;" though). But don't wanna go deeply to bike-sheading about it.<br>
<br>Dmitry<br></div></div></div></div>