We are blocking future possibility by allowing decorators before export

[trusktr]

Continued from #69 (comment)

So we decided to eliminate the possibility of decorating export just because of a small nit pick. Now we will not be able to do this:

import {mutable} from 'some-lib'

function onFooUpdate(value) {
  console.log(value)
  return value
}

// foo.js
@mutable(onFooUpdate)
export let foo = 123

// ^ Great for global app state.

import {foo} from './foo.js'

foo = 123 // logs "123"

Decorators make more sense with the thing they decorate.

Not only are people nit picking here, but we have willfully limited future and useful possibility over a simple syntax dislike.

If Object.observe can be removed at stage 3, then technically there is still room for change, and hence worth posting this issue.

[pzuraq]

As noted in the other thread, this issue has been settled. Everything you noted in your comment was discussed explicitly in plenary, read the notes if you want to see what the details were and why the decision was made.

I will be closing this duplicate, please don't reopen.

[trusktr]

As I noted in the update:

If Object.observe can be removed at stage 3, then technically there is still room for change, and hence worth posting this issue.

[pzuraq]

@trusktr no delegates wish to change this at this time. If that changes and a delegate decides that they want to reopen this issue, I will let it be reopened. Delegates are aware that the community remains divided on the issue.

If you read the notes, you will find that several delegates have stated they would explicitly block decorating of exports from ever being included in the language.

We use the issue tracker to keep track of open discussions and issues remaining with the spec, so it's not productive to have old issues open for matters that have been settled.

[ljharb]

(Also, Object.observe was at stage 2, not 3)

[trusktr]

Ah, I mis-remembered. It was implemented in various polyfills and far more used than the current stage 3 decorators have been at this point. So it was like a stage 3 thing in practice.

It is all relative, and quite a lot of subjective emotion involved (not a bad thing per se, but perhaps really ponder the future possibility of things like export decoration, which could be a very useful thing, or maybe not, but better to let the possibility be explored than eliminated).

[pzuraq]

@trusktr the possibility has been explored. The objectors had two main reasons for rejecting the idea:

1. Lack of motivating use cases. There just were not many compelling use cases and all of the ones that could be thought of (e.g. rebinding exports to different names) were shot down for reasons such as making static analysis basically impossible.
2. Syntax complexity. Parsing @dec1 @dec2 export @dec3 @dec4 class Foo {} is a very tricky task, it's easy to miss which decorators apply to which statement.

Please read the plenary notes for more details, this discussion should be captured in them, and it would probably be best to read them before continuing the conversation here.

[mhofman]

I don't see how export is relevant here. The hypothetical example seem to be about a let binding decoration, and I don't see why the proposed placement before export would be any different than for the now decided class decorators, aka the decoration is for the binding, not the export. If anything, this example reinforces the decision that no export decoration is needed and that most of the time it would be confusing if it was possible to decorate exports themselves.

Edit: sorry I missed the assignment from another module in the example. That would be a change to module semantics, which is completely out of scope for decorators, and I believe would never make it through committee.

And the fact I read it as decorating the binding shows it would be a bad idea to allow it to mean something else.