Ron Buckton

I imagine the point would be consistency between method decorators and a future function decorators proposal, that you could have a decorator that attached metadata to the function object itself...

An opaque object generally assumes that metadata should only be produced/consumed by the metadata library. However, that isn't the only use case for metadata. A compiler, might want to be...

> One way might be to simply be more explicit in the name, and have separate `context.classMetadata` and `context.functionMetadata` I just filed tc39/proposal-decorators#466 today, which proposes a similar bifurcation, i.e.,...

I'm not sure where you're getting a "shared string-based global namespace" from my example. Such metadata would live on the class itself, not globally. My intent is to allow a...

I apologize for this reply being a bit long-winded, but there are a lot of different pieces to consider related to how TypeScript would like to be able to use...

Regarding native JS emulation of RTTI, with a mutable `context.metadata` this is fairly easy to achieve in userland: ```js function getOrCreateMemberInfo(context) { if (context.private) throw new TypeError("Not supported on private...

That still doesn't put us in much better of a situation than we are with `reflect-metadata` and stage 1 decorators. You need to import a 3rd party package to use...

> I actually think that the `@type()` decorator may be a good idea even for code compiled by TypeScript. It would be a per-field opt-in to RTTI, rather than a...

Essentially, there are two options to consider: 1. Remove _Elision_ from _ExtractorAssignmentPattern_ and instead depend on discards from the [Discard (`void`) Bindings proposal](https://github.com/tc39/proposal-discard-binding). 2. Introduce _Elision_ into a cover grammar...

> Is there any other language precedent for extractor overloading? So far as I'm aware, only in typed languages. C#'s `Deconstruct` can use differing arity of the outputs to call...