Suggestion Backlog Slog, 4/1/2019 #30696

Activity

1. RyanCavanaugh commented on Apr 1, 2019

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Apr 1, 2019

   Last edited by RyanCavanaugh

   MemberAuthor

   More actions

   • Always assigning to an un-initialized variable in an exhaustive switch #30000 Allow use of always-initialized (according to types) variables
     • Ideally not an error, of course
     • How is uninitialization detected?
     • Currently switch exhaustiveness is only for return statements themselves
     • CFA does not have the type information to know that the no-op switch path is "unreachable"
     • Requires multi-pass CFA / typechecking
     • DL
     • let a!: number; and Daniel will log bug on bad error message there
   • Support max-line-length in organize imports #22991 Support max-line-length in Organize Imports refactor
     • Rabbit hole complaining about sort order disagreements
     • Is this difficult?
       • ??
     • Fine
   • Distinguish missing and undefined #13195 Distinguish missing and undefined
     • Fairly large breaking change; would need to be its own flag
     • JS lacks a good way to elide a property in an object literal
     • The in operator doesn't care about observing an undefined
     • An experiment would be interesting
   • Overload gets lost in mapped type with conditional type #29732 Overloads and mapped types, what's going on
     • We "need" to do overload resolution during instantiation
     • We always resolve based on the last signature (pure heuristic)
     • Is there a unification step we could take?
       • Hard to say & would definitely lose return type information
     • As long as there are no generics, and the return types are the same (?), we could try flattening to the tuple form
     • Anders to ponder
   • Allow contextual typing for "one-shot" functions #30017 Contextual typing of singly-used functions?
     • This feature looks like a bug in practice
     • The compelling aspect of this request is the difficulty of writing the type annotation you want here
     • Some way to resolve a discriminated union in a type position would be nice
     • Select<T, K, V> is easy to write! (let's see if that's true...)

   // One-time helper, curryable
   type Select<T, K extends keyof T, V> = T extends Record<K, V> ? T : never;
   
   // Type annotation
   const fooLogic = (foo: Select<Action, "type", "FOO">["foo"]) => { // 👍
       return {/* ... */}
   }

   • Allow augmentation of re-exported module #12607 Allow augmentation of re-exported modules
     • What is actually being described here?
       • Adding extra stuff to AClass ?
       • Something else?
     • NMI on what's being asked here
     • If the request here is to augment AClass through either name, then this is just a bug report of us following import aliases more aggressively
   • Allow tsconfig.json when input files are specified #27379 Allow providing additional files with tsconfig.json
     • Sidebar: can we warn when a local tsconfig is being ignored?
       • Why do we do this?
         • All bad decisions are due to back compat
         • How did we come up with these rules?
       • Worried about breakages in msbuild scenarios
       • Can we print a warning?
         • "Warnings are never a break, right?"
     • This issue
       • Does it augment or replace the include list? Or the files list?
       • How does this interact with exclude?
     • Someone go figure something out
   • Mapped Types should distribute over union types #28339 Mapped types should distribute over unions
     • Can't change the behavior here
     • "Fix" is to use Pick2: type Pick2<T> = T extends T ? Pick<T> : never
   • Skip typechecking; only emit (support --transpileOnly in tsc, re-open of #4176) #29651 Transpile-only builds
     • Comes with same caveats as using noEmit + babel (turn on isolatedModules)
     • Scenario is using TypeScript as Babel and something else as TypeScript
       • It's a dessert topping and a floor wax
     • We're curious how things are for this user under incremental
     • Effectively noResolve is on?
       • Yes?
       • No?
     • It's "easy" to write a tool that does this for you
     • AMF and more info
   • Allow const assertion to be use on enum types  #30690 as const on enum values
     • 👍
     • Allowed only in the case E.P where E is a literal enum
     • Include negative tests for other stuff
   • [fix] ES5 Object.keys only accepts an object #27089 Object.keys ES5 input type
     • Is this a desirable call?
       • ??
       • Doesn't seem like it
     • AMF / log an issue
2. Daniel Rosenwasser (DanielRosenwasser)

   added

   Design NotesNotes from our design meetingsNotes from our design meetings

   on Apr 1, 2019
3. zpdDG4gta8XKpMCd commented on Apr 2, 2019

   

   ZpdDG4gta (zpdDG4gta8XKpMCd)

   on Apr 2, 2019

   Last edited by zpdDG4gta8XKpMCd

   More actions

   i am sorry for being a pain in one place, but how come these first 3 of these and some more features/problems are even considered? it's like the team is out of ideas what to do next

   there are 👍 of 250+ problems waiting from the dawn of time, and being ignored for years:
   https://github.com/Microsoft/TypeScript/issues?q=sort%3Areactions-%2B1-desc

   👎React with 👎1Reacted by Trotyl Yu

   😄React with 😄1Reacted by Tyler Rick
4. RyanCavanaugh commented on Apr 2, 2019

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Apr 2, 2019

   MemberAuthor

   More actions

   Aleksey-Bykov Probably some context-setting is in order. This meeting is primarily devoted to getting yes-or-no decisions made on suggestions which have fairly clear outcomes. In other words, it's effectively a "shortest job first" throughput-maximizing endeavor where we try to pay down some of the massive triage debt we have while also getting as many suggestions accepted or declined in a short turnaround time. If a dozen people express an identifiable need for a commandline flag to print the errors in reverse order, we should be able to make that yes-or-no decision so they can either send a PR or make other arrangements.

   By its nature, this means we're looking at simple commandline flags, tweaks to definitions, highly-scoped behavioral changes, or "Is this actually a bug?" type issues.

   For larger high-impact features (HKTs, variadics, nominal types, negated types, etc) we are generally choosing these based on ecosystem need and concerns about implementation complexity. I can't take Associated Types to a room with three people, getting a consensus "yes", and be shipping it later that week - all of these larger things start with a clearly identifiable gap in the language, get discussed at a high level for weeks if not months, and eventually land as a keystone feature in a release.

   I have over a thousand pending suggestions to sort out here. In a particularly good week when all the key people are present, we can get through 20-30. Any sort order is necessarily going to give some suggestions the short end of the stick, which sucks, but this meeting literally was created to just get the freakin' number down and its agenda reflects that. Hopefully that clarifies why you see small-ball level suggestions in these notes - it's not because we're eschewing popular stuff, it's that we're trying to get through a bunch of easy decisions all at once.

   👍React with 👍8Reacted by Brendan Kenny, Titian Cernicova-Dragomir, Sean M. Vieira, David Sherret, Trotyl Yu, Trey Brisbane, Gareth Jones and Alec Larson
5. Ryan Cavanaugh (RyanCavanaugh)

   closed this as completedon Apr 2, 2019
6. zpdDG4gta8XKpMCd commented on Apr 2, 2019

   

   ZpdDG4gta (zpdDG4gta8XKpMCd)

   on Apr 2, 2019

   More actions

   so you are saying it's not a planning meeting and yet, some requests get approved for implementation, i am questioning the rationale of the original selection, some requests are created a day ago, do not have any comments let along any thumbs up, and yet they are brought for discussion with a chance of being approved, i just dont get this part
7. RyanCavanaugh commented on Apr 2, 2019

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Apr 2, 2019

   MemberAuthor

   More actions

   It is a planning meeting. It is simply not the planning meeting where All Decisions Get Made, and not the planning meeting where any of the issues you linked to could be meaningfully addressed.

   I'm facing the task here of picking 15-30 items from a list of 1,500. My algorithm here is intentionally varied; some weeks I sort by oldest, some weeks most upvotes, some weeks newest, some weeks we work off a backlog of recently-curated things. If you're trying to make an agenda where everyone stays engaged and is making good decisions, it's necessary to keep a mix of things in there.

   Sometimes a suggestion comes in and I say, "This would be easy to make a quick decision on", and it goes in the queue. #30690, for example, the first thing we said in the meeting was "This seems like an oversight that it wasn't allowed in the first place".

   Getting flak for how we choose to handle this enormous backlog of suggestions is draining and I'm trying to figure out what you want to get out of this conversation. If you want to pitch a list of 15-30 "In Discussion"-tagged items that you think we can make yes-or-no decisions on in five minutes or less each, I will no joke use that as the agenda for the next meeting. Offer is open to anyone; if you want to give us theme weeks or something (Only Commandline Flags! Only C# Keywords!) that'd be fun.

   👍React with 👍6Reacted by Sean Vieira, Tabitha Larkin, Daniel K., lju, therealmikz and Alec Larson

   ❤️React with ❤️11Reacted by Sean Vieira, Brendan Kenny, Tabitha Larkin, Trey Brisbane, Daniel K., lju, Tyler Rick, Ian Yates, Alec Larson, Daniel Levett and 1 more
8. zpdDG4gta8XKpMCd commented on Apr 2, 2019

   

   ZpdDG4gta (zpdDG4gta8XKpMCd)

   on Apr 2, 2019

   More actions

   ok, i guess you know what you are doing, thank you for write up
9. svieira commented on Apr 3, 2019

   

   Sean Vieira (svieira)

   on Apr 3, 2019

   More actions

   Thank you so much for taking the time to set the context Ryan Cavanaugh (@RyanCavanaugh) - the work that you have been doing to make the development process transparent is greatly appreciated (and one of the reasons we're using TypeScript over Flow)

   👍React with 👍5Reacted by Brendan Kenny, Tabitha Larkin, Daniel K., Tyler Rick and Alec Larson