Decorator-like syntax suggestion

[littledan]

My main concern with this proposal is the use of the string pragma syntax. One issue is that typos become silent errors, as they are just ignored as comments. I think it'd be nice if we could do this proposal in a way that would work as an extension point for more things, and I'm not sure if we want to go this way with "use strict"-style pragmas.

@rbuckton has proposed @namespace: decorator notation for decorators which do different things. I think we could reserve a namespace for built-in, static things as well. (My understanding is that's what Swift uses @ for, so we wouldn't really be innovating here.) As a straw(person), how about this:

@early: noFunctionPrototypeToString
function foo() { }

The semantics here would be that each function would need to be individually annotated to get censorship; it wouldn't be nested (I can see why this would be a disadvantage).

I think this syntax would work just fine for all the syntactic forms that we care about: function declarations and expressions, class declarations and expressions, concise methods, and arrow functions. AFAICT there's no need for any no-line-terminator-here or any other syntactic hacks; between the @ and the : we're already in pretty free territory.

We could start with this proposal being the one place where the syntax is used, and define other usages over time.

Thoughts?

[domenic]

The lack of ability to apply to a source file, or cascading in general, seems like a deal-breaker to me. Consider what it would look like to censor everything in a source file: you'd have to do this on all methods, arrow functions that are used as callbacks, accessor bodies, etc.

See also #9, where I captured some of the committee discussion as to why pragmas are the best fit. (Still need to translate that into the readme.)

[littledan]

Among the points in #9, I guess "backwards compatible" is the biggest mismatch? I am curious why direct source backwards compatibility is a goal here rather than trabspilability.

For censoring everything in a source file, I wonder if your original proposal for an out-of-band signal (e.g. HTTP header on the web or parameter in a build system for standard libraries) would be a good idea.

[domenic]

The out of band signal does not fit the use case presented in this repository, where library authors (who generally only control the source code they distribute) want to preserve encapsulation.

[littledan]

What if we used this syntax, but said that it led to cascading semantics?

[domenic]

Then it would not be backward-compatible, as discussed upthread...

[littledan]

How strong is the backwards compatibility requirement? It seems like we've been pretty successful in adding new syntax to JavaScript, and people use build systems to convert to the old syntax. This directive is readily transpilable (with a monkey-patched Function.prototype.toString).

[domenic]

I believe @erights was the one most interested in backward-compatibility here.

Can you explain why you want to break backward compatibility with your new, as-yet-unused-anywhere syntax? It seems like you have a syntax in search of a problem to solve, which seems backward to me.

[littledan]

Well, I'm concerned about explosions of different syntax; I think we can use decorator-like syntax for various different problems that we're trying to solve. I'll post an explainer soon where I explain my concerns with string pragmas and other use cases for decorator-like syntax.

[domenic]

Hmm, I too am concerned about the explosions of different syntax. As such, using a preexisting syntax instead of introducing a new one (which has some pseudo similarities to decorators, like using the @ sign, but seems otherwise unrelated) is worrying to me.

[littledan]

Right, I think this is a broader question than just this repository. I agree that, if we use this decorator-like syntax just for this one single case, it'd be adding extra complexity that's not really justified. Let's discuss at the next TC39 meeting whether we want to consider using more general decorator-like syntax as a pattern going forward.

[michaelficarra]

The committee chose to use a directive-based approach for this feature.

[hax]

@michaelficarra Links to related tc39 notes may help others to find the further discussion?

[littledan]

It's fine with me to close this issue, but I remain somewhat skeptical of using a string-based directive, and I don't remember any sort of consensus affirming that we agree on a directive. I think we could call this truly settled once the proposal goes to Stage 3 with a string-based directive.

[michaelficarra]

@littledan during my most recent presentation of this proposal, I explicitly asked for objections to each of the following decisions:

• the limitation to the use cases outlined in the presentation
• a two-directive solution (as opposed to dynamic alternatives presented)
• a third directive, as requested by @erights, if follow up discussions found that to be necessary

None were raised.

[littledan]

Ah, sorry, I must not have heard well from remote. Probably when the notes are published, the results will be clear. (Did you ask for objections to string-based pragmas?)

(However, note that, in the past, when I asked for objections about various decorators issues, people didn't end up raising them until the proposal to promote it all to Stage 3.)