Proposal: Selector/Select Expression

Brian Boyko brian.boyko at
Sun Jun 23 09:30:35 UTC 2019

Howdy. First post to es-discuss.

I've been thinking about the proposal.  I would recommend against it, main
reason being that it makes the language a bit harder to read and understand

Here's why. As an example, you've listed

```const getEmail =;```

as a possible use case. The problem with this is that what you're
essentially doing is adding a *third* way to write a function (other than
"const foo = x => x" or "function foo (x) { return x }"

Now, I don't mind the arrow operator since it automatically binds "this"
and makes tracking the scope of "this" easier (as well as making "this"
behave more like an object-oriented programmer coming from a primarily OOP
language would expect "this" to behave). Trick is, of course that in so
doing, we've added a "special occasion" where if we *do* need the function
to have it's own "this" scope, we need to use the longer syntax. That "=>"
is shorter to type encourages it's use as the default, and when a coder
looks at someone writing out "function" it warns them that something funky
is about to happen with "this."

The problem with the proposal, as I see it, is that it creates a function
that looks, at first glance, to be a variable assignment. Granted, that
leading "." does look different from most variable assignments, but it's
easy to overlook. Whether it's with an arrow function or the function
keyword, when a function is defined, it is always defined with "()"
somewhere in it. It is, in fact, what makes functions *look different* at a
skim-level of reading comprehension, from things like assignments and

By adding this new way of writing functions without () in the syntax, you
increase the cognitive overhead of the programmer, which is something we
want to avoid.

A concise programming language is not a programming language with the
fewest characters, but the programming language with the fewest characters
*necessary to make meaning clear.* I just don't think that the proposed
syntax clearly indicates what it does, and violates the principle of least

So - that's my two cents as a person who isn't a language *expert* perse
but does have to use ES on a daily basis.

It's still a good problem to solve, though, as (x) => does
come up quite often.  But perhaps this should be a proposal in a helper
library like lodash that isn't something that all javascript programmers
learning the language need to internalise. That way you could write:

const getEmail = _.drill("", value_if_undefined)
const getEmail = _.drill(['contacts', 'email'], value_if_undefined)

get nearly the same amount of code golf, and be able to use it when you
need it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list