-
-
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
Explain why Readonly array is not good idea #987
Comments
It's ok to accept I think the best solution so far is to accept Note: we have the same problem in |
@gcanti ReadonlyArray really should be banned in fp-ts ecosystem. It's only pain without any measurable benefit. I just spend another hour with |
In practice it already is (except for |
Sorry, but I don't get why the use of ReadonlyArrays are great, and I'd be glad to submit a PR to support them more (either with overloads to return ReadonlyArrays when operating on ReadonlyArrays or using ArrayLike and returning Arrays as @raveclassic suggested) if that's ok with the maintainers. |
"ReadonlyArrays are great" if everything is read-only array otherwise poor developers have to cast them all the time. If fp-ts people are happy with it casting all the time or not using mutable arrays at all, then ok. |
In our projects we're enforcing using |
Actually I'm considering to drop support for mutable modules in v3, #1226 |
📖 Documentation
Readonly arrays are great to prevent accidental mutations via sort method, but PITA when used with code requiring normal Array. Long story short, it's: Use it everywhere, nowhere, or cast all the time.
I didn't find any other frictionless solution from the DX perspective than not using readonly arrays at all.
I believe it should be mentioned in the documentation.
The text was updated successfully, but these errors were encountered: