Repository navigation
Suggestion Backlog Slog, 4/20/2016 #8228
Description
Activity
Postponed to Monday
- negating type constraints #7993 Negative type constraints
- Ryan's 'workaround' is disgusting 😄
- See if other scenarios appear
- Better display representation for intersection types #7705 Better display of intersection types
- Agree the proposed behavior is desirable
- There are potentially some differences between
T & Uand its decomposed form?- We can't think of any
- What do we do if one is an object type and one isn't?
- Just do this for the anonymous types of the intersection
- It's actually really hard and dangerous
- Because anonymous types can be self-referentially recursive
- Potential for a lot of runaway bugs
- Close to Too Complex given the risk/reward tradeof
- Accepting PRs but they need a giant test suite
- Destructured parameter should not enforce presence / non-nullability from type annotation on a property that's default-initialized #7678 Destructured parameter should not enforce presence / non-nullability from type annotation on a property that's default-initialized
- Sympathetic that this is annoying
- Real problem is that there's no syntactic room in
Component1to put a type annotation on justpropC - Axiom: Type annotations always win
- 👎 Too Complex
- Allow ArrayLike as a spread source #7596 Allow ArrayLike as a spread source
- If we look for ArrayLike, this would work
- Compat problem with ES6 and surrogate pairs on strings
- Also enables other good behavior like DOM collections
- Does anyone spread a string on purpose?
- 👍 Accepting PRs and live with surrogate pair compat issue
- If we look for ArrayLike, this would work
- Suggestion: readonly constructor parameters #7590
readonlyconstructor parameter properties- Why didn't this work before? Unsure (keyword soup fear?)
- Committed for 2.0
- 👍
- Excess properties are not checked e.g. in callbacks #7547 Excess properties not checked in callbacks
- Agree this is not the ideal behavior
- Caused by widening the return type of function expressions
- Looking at Don't widen return types of function expressions #241 trying to figure out its status
- Why do we have this behavior today?
- The types that go in to
widenonly come fromcheckExpression, which have a limited domain of non-circular types - So we'd need to modify the widening logic to handle self-referential recursive types
- The types that go in to
- Confusing but workaround is simple (add a return type annotation to function expression)
- If Don't widen return types of function expressions #241 keeps happening, address it
- Too Complex but keep an eye on function expression return type widening
- Suggestion: Implied Promise return type in async functions #7284 Implied
Promisereturn type in async functions- Working as intended - Spooky action at a distance hinders readability
- 👎
- Allow
superconstrains for type parameters #7265 Allowsuperconstraints for type parameters - JSX: a way to make all the properties of value-based elements optional #7004 A way to make all properties of value-based elements optional
- Architectural/perf concerns about the amount of indirection this requires
- e.g. what is the internal behavior of
Optionalize<string>? - Generics prevent assumptions here
- Important is that union/intersection types are always top-level
- e.g. what is the internal behavior of
- Very large work item, but this appears in a lot of frameworks
- e.g. potential to construct previously unconstructable things (e.g. union types which have sub-union types as members)
- Think about it some more
- Architectural/perf concerns about the amount of indirection this requires
- More specific JSON parse reviver argument in lib.d.ts #6955 More specific
revivertype inJSON#parse- Breaking change for people who got a contextual
anyand indexed into an array- Seems unlikely and fix is very simple
- 👍
- Breaking change for people who got a contextual
- Readonly indexer and constructor usage: question #6781 Readonly indexer and constructor usage
- What's the intent of a readonly index signature? Disagreement
- What's the actual code? Need to understand the scenario better
- Allow defining static index signature #6480 Allow defining static index signature
- 👍 Accepting PRs, should be reasonably straightforward
- Leak of
noImplicitAnychecking with private static property #6415 Leak ofnoImplicitAnychecking with private static property- A type query should never generate an implicit any
- 👍 but fix is that it should be illegal to use the
typeofa private member to annotate a public member
- Provide an official set of Coding Guidelines #878 Provide official coding guidelines
- Nope
- Partial classes #563 Partial classes
- Just sugar for
interface A { methods; }, A.prototype.methods = ... - Allow property declarations and methods, but not property initializers (no way to emit)
- Allow statics as well (including initializers, since we can emit those)
- People are already sort of doing this already
- Bikeshed
partialkeywordextension classis the name C# would have called it but there isn't a clear "master" declaration like there is here- Confuse people by making it almost the same as C#, but not?
- Or have a new keyword that we have to explain is 'close to'
partial - Which will be preferable?
- Just sugar for
- Special
bottomtype #3076 Special 'bottom' type- Out of time
- Default generic type variables #2175 Default generic types
- Out of time
- negating type constraints #7993 Negative type constraints
- locked and limited conversation to collaborators
on Jun 19, 2018
readonlyconstructor parameter propertiesPromisereturn type in async functionssuperconstrains for type parameters #7265 Allowsuperconstraints for type parametersrevivertype inJSON#parsenoImplicitAnychecking with private static property #6415 Leak ofnoImplicitAnychecking with private static propertybottomtype #3076 Special 'bottom' type