-
-
Notifications
You must be signed in to change notification settings - Fork 504
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider dropping support for mutable modules #1226
Comments
As a functional library it's OK to enforce immutability. I would get rid of all |
Would love to see that readonly is the default in the whole |
|
There are two options I guess: Option 1 Keep the Option 2 Remove all the mutable modules and rename |
@gcanti based on a similar conversation... this explains my vote :) |
We can see this issue in two lights:
...or:
I tend to like the first philosophy. |
Readonly arrays/records (using ts |
Since this may hinder adoption by less pure codebases, throwing another option out there: switch the defaults, so the module |
I'm currently in a world of hurt working heavily with fp-ts trees and otherwise readonly data, having to constantly be converting between readonly and mutable arrays. Additionally, monocle-ts's This could be solved by moving to all mutable data-structures, or all immutable. export type DeepWritable<T> = { -readonly [P in keyof T]: DeepWritable<T[P]> };
export function castWritable<T>(x: T): DeepWritable<T> {
return x as DeepWritable<T>;
} |
I have been stumbling over However, if you type your functions so their return values are |
Namely:
The text was updated successfully, but these errors were encountered: