Eris

This is still a problem, IMO. E.g. the following code constructs a type, which includes properties from type `A` except those present in `Bar` or given object type (effectively `{...

Possible problem with bigint enums is ambiguous reverse mapping. For example, the following code will not work as expected: ```typescript enum A { a = 1, b = 1n, }...

Also, reverse mapping for bigint members probably aren’t critical. These members most probably will be used for bit flags, where reverse mappings may not work even with regular numbers: ```...

Here is a possible implementation of bigint const enums (assuming TSC host runtime supports bigints): https://github.com/miyaokamarina/TypeScript/commit/1fbcc8e226697c648242aaf6daee75244fe0a9fb

@yseymour, I don't understand why this should be an error. Both const and non-const enums already allow mixed member types. Would it be an error, if string and bigint members...

For example, underlying types may be specified either using leading keywords (`number enum`, `bigint const enum`), or using the `extends` clause (`enum E extends string`, `enum F extends bigint`). But...

Well, it can be worked around like this: 1. Call `makepkg` with a custom `--config` with `DLAGENTS` substituted by wrappers, that report progress in a machine-readable way. 2. Then interpret...

I think, omitting this feature will lead to inconsistency with other decorators flavors (and with tagged templates). Both proposals allow passing parameters, providing default parameters, destructuring, etc.; both proposals allow...

Done: https://github.com/tc39/proposal-extended-numeric-literals/pull/24.

If I understand the spec and current behavior (with no decorators) correctly, this is the correct behavior: 1. The decorator expressions (e.g., `fn()` call in `@fn()`) are evaluated and stored...