-
Notifications
You must be signed in to change notification settings - Fork 30
ImmutableArray #152
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
ImmutableArray #152
Conversation
JavaScript and .net combine both mutable and immutable array functions in the same module because it is convenient for the programmer and has performance benefits. The programmer can use immutable functions most of the time and carefully switch over to a mutable "push" for performance benefits. I think arrays are mutable almost by definition. I like immutability, but just don't think Array is a natural fit for it. If we have such a module that represents data structures NOT in JavaScript I think other data structures are higher priority or more useful. For example the Belt Set and Map allow you to define the item equality operator, without which the JavaScript Map and Set are somewhat useless. Here are immutable collections for .net - lots of interesting ones to choose from. https://learn.microsoft.com/en-us/dotnet/api/system.collections.immutable?view=net-7.0 Personally I find a NonEmptyArray to be useful. And finally I think lazy sequences are extremely useful, especially for working with arrays, are immutable, and are part of most mature frameworks. I think sequences are far higher priority than immutable arrays. https://github.com/jmagaram/rescript-seq As for this particular code, once you've got an array it seems like you'd need a |
Correct. This would mean you would have to convert this to a regular Ideally this would be similar to the
This would behave similar to a What I would like is something that maps to a JS Array under the hood but doesn't allow mutation, and has some type of guarantee from the compiler that the array hasn't been mutated by something else. If I do need to interop with a regular Here's another example: let t1: ImmutableArray.t<int> = [1, 2, 3]->ImmutableArray.fromArray
let t2 = t1->ImmutableArray.toArray
let t3 = t2->Array.push(4)
Console.log2(t1, t2) // [1, 2, 3], [1, 2, 3, 4] My original array of Would it make sense to call this a |
Notice casting one type of array to the other (either direction) without copying is unsafe. |
In case one wants to intentionally be unsafe (immutable arrays can actually be mutated by code that type checks), copying TS behavior, one would need to explain the benefits of the choice. |
Correct, in order to move from a mutable array from immutable, or the other way around, the array is copied.
TypeScript does it's best to try and stop you from mutating a readonly array. You can't do this for example: function fn(a: Array<number> | ReadonlyArray<number>) {
return a.push(1) // Property 'push' does not exist on type 'readonly number[]
} TypeScript also doesn't let you swap the type from a function convert<T>(a: ReadonlyArray<T>): Array<T> {
return [...a]
}
function convert<T>(a: ReadonlyArray<T>): Array<T> {
return a //The type 'readonly T[]' is 'readonly' and cannot be assigned to the mutable type 'T[]'.
} |
Yeah, TypeScript isn't perfect. Hopefully this is something that can be enforced going in both directions with ReScript. |
An addition to add an
ImmutableArray
type to Core.Conversation over here: #23
This just omits any functions that would mutate the original Array and adds a function to create an
ImmutableArray
from anArray
.Here's an example of how to create one:
And here's the output:
I made
fromArray
useslice
to create a copy of the original array. This means that once we create anImmutableArray
from a normalArray
we don't have to worry about the original array mutating. Of course we only have that guarantee that no one will mutate the array if all of our source code is written in Rescript.I'll address these items if this gets the go ahead to be added.
TODO: