<div dir="ltr">The world is awash in subjectivity. <div><br></div><div>We can nevertheless hope to find broad agreement on at least a transitive ranking of attributes such as readability; if we don't think we can, then we are epistemological nihilists with no criteria whatsoever on which to base our language design decisions and this mailing list would have no raison d'etre, since we would never be able to align on anything.</div><div><br></div><div>However subjective the notion of readability, I think few would disagree that the first fragment below is more readable than the second.</div><div><br></div><div><div>```</div><div>.name</div><div>```</div><div><br></div><div>and</div><div><br></div><div>```</div><div>({name}) => name</div><div>```</div><div><br></div><div>The first is also more reliable by most measures, because it removes the possibility of misspelling one of the instances of ```name``` in the second, which we would prefer not to rely entirely opn type checkers or linters to pick up.</div><div><br></div><div>Yes, to read the first does require additional knowledge, namely of the fact that the syntax ```<dot>property``` denotes a function to retrieve the value of the property by that name. But this is no more a readability problem than the fact that one must have knowledge of the English worrds in a sentence in order for them to be "readable". Such knowledge is often referred to by terms such as "cognitive footprint". Yes, this proposal does have a cognitive footprint. But all language features have cognitive footprints, requiring that people writing and reading code using the feature have knowledge of the feature. The issue then becomes the *size* of the cognitive footprint in relation to the benefit--an equation both sides of which involve subjectivity...</div><div><br></div><div>Of course, I did not mean to imply that readability or reliability in and ot themselves are either necessary or sufficient for a new languge feature, There are many other aspects, as many as a dozen, which have been discussed and defined in earlier threads.</div><div><br></div><div>Bob</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 12:08 PM guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</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"><div dir="ltr">> If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.<div><br></div><div>The term "readable" is entirely subjective. As far as am aware there is no standard for "readable" (in any language, coding or not). Even if such criteria for "readable" did exist in some institutional document, no author of code (or anything else) is bound to recognize or adhere to any such subjective and arbitrary criteria. </div><div><br></div><div>What specific definition of "reliable" is being used, and what are the cases that demonstrates using destructing assignment is not "reliable"? </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <<a href="mailto:rtm@gol.com" target="_blank">rtm@gol.com</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"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Sat, Jun 22, 2019 at 10:59 AM guest271314 <<a href="mailto:guest271314@gmail.com" target="_blank">guest271314@gmail.com</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"><div dir="ltr">Does not destructuring assignment provide a means to achieve the requirement?</div></blockquote><div dir="ltr"><br></div><div dir="ltr">If the requirement is merely to write a function to pick properties, yes. If the requirement is to do that in a more concise, readable, reliable way, no.</div></div>
</blockquote></div>
</blockquote></div>