Proposal: Property Accessor Function Shorthand

Bob Myers rtm at
Mon Nov 25 05:17:07 UTC 2019

This is a great proposal which I hope can attract the support of the powers
that be. The arrival of optional chaining seems to indicate a renewed
interest in optimizing the way properties are accessed--which after all is
a big part of what JS does for a living.

Using `.a` to denote a function to retrieve the value of the property named
`a` was actually part of an earlier proposal for a number of ways to extend
dot notation. I won't link to that proposal since it's obsolete now, but it
also allowed

const getFirstName = .name.first;

With optional chaining syntax, this would presumably also be able to be
written as `.name?.first`.

The earlier proposal also suggested extending this notation to arrays, so

const head = .[0];

In case you are interested, the current version of the proposal for
extended dot notation limits itself to accessing multiple properties with
the syntax `.{a, b}`. It can be found at

FWIW, the syntax `.propName` does appear to be syntactically unambiguous.


On Sun, Nov 24, 2019 at 4:51 PM <sup at> wrote:

> Hi folks! I'd like to hear your feedback on a proposal idea I have and
> that I couldn't find anything on. Here is what I have so far.
> With the rising popularity of functional programming patterns in
> JavaScript, functions that take an object and return the value of a
> property are ubiquitous. These are some popular examples:
> ```js
> // filtering by a boolean property
> const activeProducts = products.filter(product =>;
> // mapping
> const productNames = =>;
> // sorting, grouping, etc
> const sortedProducts = _.sortBy(products, product =>;
> const { true: activeProducts, false: inactiveProducts } = _.groupBy(
> products,
> product =>
> );
> ```
> This pattern is so common in fact that libraries like `lodash` (and
> frameworks) often also accept passing the name of the property as a string:
> ```js
> const sortedProducts = _.sortBy(products, "name");
> ```
> However, this technique has various problems:
> 1. It requires extra code from the library authors. With its typical
> disadvantages.
> 2. It has a potential negative impact on performance.
> 3. It is not easily statically analyzable, which makes it hard to
> type-check, infer, and for tooling to catch typos.
> Several languages have solved these problems by introducing some syntactic
> sugar that simplifies the definition of these functions. My favorite
> example is Elm's: `.property` shorthand [1]. If JavaScript supported this
> syntax, we could write the previous examples as:
> ```js
> const activeProducts = products.filter(.active);
> const productNames =;
> const sortedProducts = _.sortBy(products, .name);
> const { true: activeProducts, false: inactiveProducts } =
> _.groupBy(products, .active);
> ```
> This is, in my opinion, nice to read and write. Besides, since this
> expression simply yields a function, it would not have any of the problems
> the string approach has.
> Combined with the pipeline operator proposal, it would allow code like the
> following:
> ```js
> orders
>   |> filter(.active)
>   |> flatMap(.products)
>   |> .length
> ```
> Lastly, engines might be able to optimize this further (or more easily)
> than normal functions since functions defined this way would be restricted
> to returning a constant property of the object that is passed to them. They
> would not be able to have any other expressions or statements in them.
> Unfortunately, they would not be considered automatically pure because
> users can implement side effects in property getters or Proxies.
> I could not think of any syntax ambiguity this could cause, but I would
> appreciate your thoughts in this regard. It does look similar to the RHS of
> a Member Expression, but it would not be ambiguous because the two would
> not be allowed under the same contexts. The F# community has had an
> interesting ongoing conversation [2] about the topic, but it is my
> understanding we would not have these problems in JavaScript since Call
> Expressions require parenthesis.
> [1]
> [2]
> I am looking forward to hearing your feedback!
> Agustín Zubiaga
> Head of Engineering @ PINATA
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list