You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
modulerecGlutinumopenFable.CoreopenSystem[<Erase>]typeExports=interfaceendtypeValue=
U2<string, float>[<AllowNullLiteral>]typeLogger=abstractmemberlog:value:string ->unitabstract member log:value:float ->unit// abstract member log: value: Value -> unit // Should we keep this version ?
The Value type should probably be kept if the user needs to write helpers or API depending on that type.
For the first implementation, we are going to try removing the type reference declaration if only used inside of method overloading.
I don't think we will always be able to remove that type definition. For example, if the type reference i used as the type of a property we will not be able to remove it.
But I updated the original issue to try removing the type reference and we will see where it cause problems.
Yes, if a type is used as a return value in the same library or as property then it can not be split into overloads only. But I had the impression such types are most often used just as arguments.
It is then basically the same as using overloads.
TypeScript documentation:
translates into
We should also tries to convert union type coming from type reference:
translates into
TheValue
type should probably be kept if the user needs to write helpers or API depending on that type.For the first implementation, we are going to try removing the type reference declaration if only used inside of method overloading.
Example of npm package using this features:
Day.js
The text was updated successfully, but these errors were encountered: