Open cefn opened 1 year ago
Thanks @RyanCavanaugh for the vote of confidence that this might be an enhancement.
The original example included motivating context (a sketch of a function decorator, which would actually consume the narrowed inferred type).
However, an even simpler illustration to demonstrate the problem is below, where autocompletion of the last argument to narrowFn
draws from the already-inferred Narrow
when it should draw from Wide
.
Unless the Narrow
Generic is explicit, the argument list actually drives the inference, rather than following it. Autocompletion should therefore support extending the list that drives Narrow
with other candidates from Wide
.
type Wide = "artist" | "baker" | "candlestickmaker";
function narrowingFn<Narrow extends Wide>(
...roles: [Narrow, ...Narrow[]]
) {
}
narrowingFn(
// a cursor at the end of `candle` fails to autocomplete to `candlestickmaker`
"artist", "baker", "candle"
)
Bug Report
In the following example typescript IS able to judge the set of valid strings, (as shown by the compiler error), but somehow autocompletion from the language server CAN'T resolve that set. It resolves instead to the set of strings already populated, as shown below in screenshots from the typescript playground
Ideally this approach should have editor autocompletion support constraining strings to type
Role
, NOT typeEvidenced
. The typeEvidenced
is actually inferred from the items being edited right now so the programmer should be able to draw from the broader setRole
.π Search Terms
Autocompletion, inferred, generic, constraint, "too narrow"
π Version & Regression Information
β― Playground Link
Playground link with relevant code
π» Code
π Actual behavior
The set of strings for autocompletion is initially empty, when it should be populated by
Role
. After one or more entries have been provided to the list, it then autocompletes only to strings which are already provided.π Expected behavior
The set of strings for autocompletion of the arguments to the
tag
function should be populated byRole
Background
The motivating example is within a portfolio of narrative content (interactive fiction-style) using Generator functions. This wrapper function defines a composition function type to evidence roles either by invoking the callback between yields (when a yielded narrative references that role), or if that hasn't happened by calling the callback for those roles when the function eventually returns (allowing very terse definitions for simple narratives without requiring inline callbacks).
This ensures that not referencing at least one role is an error, and offers the delight that narrative elements which touch on some role can lead to an immediate update of the displayed model (showing which roles have been evidenced).
The central purpose of this typing is to assist with editor support, so not being able to have autocompletion is a real dead-end.