Effect-TS
Move type helpers from nested namespace to the top-level namespace
What is the problem this feature would solve?
Is there a particular reason of having type helpers in nested namespace e.g. Effect.Effect.Success, Stream.Stream.Success? It feels cumbersome to use it like this
What is the feature you are proposing to solve the problem?
I checked some modules and didn't found conflicts. What do you think about moving these type accessors to the top level e.g. Effect.Success, Stream.Success, mark Effect.Effect.Success as deprecated and remove in the next major?
Just BTW – TypeScript team consider namespaces as mistake https://www.youtube.com/watch?v=tXK50czRbdA&t=990s (interview of Anders Hejlsberg – the creator of TypeScript)
At some point we will likely change strategy for the inference helpers: https://github.com/Effect-TS/effect/issues/2982
At some point we will likely change strategy for the inference helpers: #2982
it's not a change of strategy, it's an addition to, the type helpers don't work always for example you can't use interface X extends typeof A.B
What is the problem this feature would solve?
Is there a particular reason of having type helpers in nested namespace e.g.
Effect.Effect.Success,Stream.Stream.Success? It feels cumbersome to use it like thisWhat is the feature you are proposing to solve the problem?
I checked some modules and didn't found conflicts. What do you think about moving these type accessors to the top level e.g.
Effect.Success,Stream.Success, markEffect.Effect.Successas deprecated and remove in the next major?Just BTW – TypeScript team consider namespaces as mistake https://www.youtube.com/watch?v=tXK50czRbdA&t=990s (interview of Anders Hejlsberg – the creator of TypeScript)
runtime namespaces are considered a mistake not type level namespaces, also the "mistake" refers to a non standard JS runtime feature that crosses multiple files, it has nothing to do with nested types.