Suggestion Backlog Slog, 11/2/2020

[DanielRosenwasser]

Disallow primitives on the right of in

#41317

Approved.

To avoid breakage on unconstrained type parameters, we're thinking to check if the type is assignable to the union of all primitive types - or if it contains any primitive type (e.g. number, string, boolean, bigint, symbol, null, undefined). isTypeAssignableToKind might be one thing to use here, if not, just use isAssignableTo.

If that's still too breaky, maybeTypeOfKind is a helper that can do this pretty quickly.

The more thorough version of this would be to check whether the type on the right side of the in has to be assignable to object. We could run that on the RWC.

this gets narrowed to NonNullable<this> in ?.

#41340

• this in parameter position was never really coherent
• Could technically never really have a parent of type this.
• Maybe we should narrow left sides of the . and ?. in argument positions.
• If we rejected a NonNullable after every . it might get rough.
  • Only need to do it when feeding a dotted name back into a deeper method call.

Seems like any reference to the left of a . or ?. should in principle be narrowed, but we have concerns around the control flow graph. We would accept an experiment PR, but we are not committed to this, especially if there are perf/memory ramifications.

Destructuring array, ability to explicitly tell the variable is unused

#31388

Seems fine!

Kind of cool aside: C# has a new rule that you can have multiple variables named _ provided that they're declared in the same scope.

[yume-chan]

Disallow primitives on the left of in

Should be right?

[DanielRosenwasser]

Yes, fixing now