Open MunMunMiao opened 5 days ago
I don't understand the scoping for these ref
type parameters. What does it mean for both define
and example
to have access to the same Tref
? It almost feels like #31894. How does this differ from that?
For #26242 I think it would be almost required for the type parameter to be scoped to the function and not some outer scope. What are the benefits of ref U; declare const f: <T>(u: U) => F<T, U>
compared to something like declare const f: <T, U=infer>(u: U) => F<T, U>
?
The purpose is to address the issue of privatized generics and optional generics You can refer to my example 1.
(aside, you've got the
[]
in the wrong place in your first example)I don't understand the scoping for these
ref
type parameters. What does it mean for bothdefine
andexample
to have access to the sameTref
? It almost feels like #31894. How does this differ from that?For #26242 I think it would be almost required for the type parameter to be scoped to the function and not some outer scope. What are the benefits of
ref U; declare const f: <T>(u: U) => F<T, U>
compared to something likedeclare const f: <T, U=infer>(u: U) => F<T, U>
?
When we need to infer the return value a function, we need to infer it the function input values. This process does not require user input. However, the existing design approach requires that the generic variable be defined on the function, the user to interfere with our inference.
function define<T, Options extends Option[]>(value: T, ...agrs: Options): Ref<Options> {}
// In this case
// we do not want the user to set a second generic because it will interfere with our inference of args,
// but we need the user to fill in the first generic to constrain the value.
define<string, any>('')
// So I need to hide my `Options[]`
ref Options
function define<T>(value: T, ...args: Options): Ref<Options> {}
define<string>('') // This is great.
I still don't understand what it means for two different functions to access the same ref
.
I also don't quite see the use case for preventing a user from manually specifying the type argument. You say "interfering with our inference" but why would that be a problem? What is the use case for private generics? Could you show an example where a user "interfering" with inference leads to a bad outcome?
I still don't understand what it means for two different functions to access the same
ref
.
For example, the code of Vue. Link Can be used in overloaded or more functions of the same type (this requires more examples to be given by everybody, and the use of the same ref for multiple functions is just one possibility)
I also don't quite see the use case for preventing a user from manually specifying the type argument. You say "interfering with our inference" but why would that be a problem? What is the use case for private generics? Could you show an example where a user "interfering" with inference leads to a bad outcome?
you can see this Playground
this's use ref syntax Playground
π Search Terms
β Viability Checklist
β Suggestion
Background
The current version of TypeScript often requires explicitly passing multiple generic parameters, leading to code duplication and redundancy in certain scenarios. Inspired by TypeScript Issue #26242, we propose a new keyword
ref
, aimed at simplifying the reference and application of generics, and enhancing the readability and maintainability of the code.Function Description
The keyword
ref
is used to declare a generic reference, which can be reused in functions, classes, or other generic definitions without the need for repeated declaration. Usingref
, one can define default values for generics, and it supports exporting and cross-file referencing.Syntax
π Motivating Example
Solving the Optional Generic Input Problem
Use
ref
to simplify function definitions, automatically infer generic parameters, and achieve private generic reference functionality:Cross-Function, Cross-File Constraints
ref
supports cross-file referencing, achieving unified type constraints:Conclusion
This proposal aims to simplify the use of generics by introducing the
ref
keyword, thereby enhancing TypeScript's development efficiency and code quality.For instance, Vue.js V2 v3-component-options.d.ts#L75 If there is a
ref
keyword, then won't be so many generic variables stored on the function, and the code will be much cleaner.We look forward to community feedback and further discussion.
βοΈWarningβοΈ
This proposal does not conflict with optional input generics, but it can solve problems such as private generics.