version 0.0.10 (remove readonly)

[gcanti]

No description provided.

[adrian-gierakowski]

@gcanti sorry to be nosy, but would you mind explaining the reason for this change? I’m asking since I work on code based where this linting rule and wonder if this change would make it more difficult for me to interface with fp-ts. I’m also curious what’s the particular use case which motivated this change as previously most types in fp-ts world were defined as readonly. Thanks!

[mikearnaldi]

Probably my fault :) https://twitter.com/MichaelArnaldi/status/1601535981949456385 the primary reason for this change is not to force readonly, generally speaking readonly doesn't give any guarantee about mutability (or better about something being immutable) and a readwrite types like A[] are assignable to the readonly variant e.g. readonly A[] so by not forcing readonly we should be able to be more compatible with both the users that like to have things readonly and those who don't

[adrian-gierakowski]

@mikearnaldi I am aware of the issue you mentioned in the twitter post but I have a feeling you might be giving up too early.

There is a push towards real immutability in js and ts. For example: https://github.com/tc39/proposal-record-tuple

Is there an actual use case in which these types being readonly creates a problem? Or is it being done just in case?

[mikearnaldi]

@mikearnaldi I am aware of the issue you mentioned in the twitter post but I have a feeling you might be giving up too early.

There is a push towards real immutability in js and ts. For example: https://github.com/tc39/proposal-record-tuple

Is there an actual use case in which these types being readonly creates a problem? Or is it being done just in case?

That proposal has nothing to do with readonly if anything I am looking forward to that proposal being accepted and becoming a standard so we could finally treat normal arrays and records as mutable for the purpose of Equal where currently we are comparing by default everything by value.

If that proposal gets accepted though the TS implementation will not be able to use readonly they will need to introduce a concept of immutable of some sort otherwise a mutable value could be passed in place of an expected immutable one.

In regards of actual problems keeping readonly, yes the real case is all the people who don't use readonly that are currently struggling (because a readonly cannot be assigned to a non readonly, rightfully), in modules such as ReadonlyArray we always copy and return fresh arrays, those are in nature mutable and there is no issue with the user building up a pipe of array computations to define a base array and then mutate it, this solution still allows the user to chose if they want to use readonly in their own types they con do so without issue.

[adrian-gierakowski]

Btw is there a publicly accessible channel where development of fp-ts 3 and effect-ts 1.0 is being actively discussed? I look forward to using both libs in my projects and would love to keep up to date with design decisions which are being made. Thanks!

[mikearnaldi]

Probably the best place is Effect's discord we have a quite active #fp-ts channel https://discord.gg/hTJ4cRd8Ah where many times ideas are shared, I'd have to say though that most of the times we kind of privately weighting a few different ideas and then advance one in order to get feedback as at this stage discussing everything publicly at length would mostly just slow down the process and we have years of cumulated feedback that we want to address first. In that optic any big change such as this one or for example addition of some methods to types are just advanced as a way to get feedback and are not final decisions

[adrian-gierakowski]

Probably the best place is Effect's discord we have a quite active #fp-ts channel https://discord.gg/hTJ4cRd8Ah where many times ideas are shared, I'd have to say though that most of the times we kind of privately weighting a few different ideas and then advance one in order to get feedback as at this stage discussing everything publicly at length would mostly just slow down the process and we have years of cumulated feedback that we want to address first. In that optic any big change such as this one or for example addition of some methods to types are just advanced as a way to get feedback and are not final decisions

Thanks. It’s not like I’d like to participate in decision making but just learn from the discussions.

[mikearnaldi]

Probably the best place is Effect's discord we have a quite active #fp-ts channel https://discord.gg/hTJ4cRd8Ah where many times ideas are shared, I'd have to say though that most of the times we kind of privately weighting a few different ideas and then advance one in order to get feedback as at this stage discussing everything publicly at length would mostly just slow down the process and we have years of cumulated feedback that we want to address first. In that optic any big change such as this one or for example addition of some methods to types are just advanced as a way to get feedback and are not final decisions

Thanks. It’s not like I’d like to participate in decision making but just learn from the discussions.

It's not that, it's more that putting too many things together out at the same time usually confuses when instead we ship something and ask for feedback it's way more straightforward :) most of what we are trying to do is to improve on all the long standing issues revisiting the trade-offs made, a good example of that is also the design of @fp-ts/schema that was based around the feedback that the lacking of combinators such as pick/omit was too much pain, when in doubt we do discuss a lot in the channel too