feat: remove Js.TypedArray2, use labaled arguments for Js.Typed_array #899
Conversation
|
What is the policy for naming of modules in |
| external sortInPlace : t -> t = "sort" [@@mel.send]\ | ||
| external sortInPlaceWith : t -> f:(elt -> elt -> int [@u]) -> t = "sort" [@@mel.send]\ |
There was a problem hiding this comment.
Maybe we could consolidate these two making f optional?
There was a problem hiding this comment.
I didn't do this one on purpose because then you'd need the unit argument to sortInPlace. I feel like the tradeoff is justified when there are other labeled arguments but perhaps not in this case.
If you feel strongly, we can reconsider. I think Js.Array and Js.String have similarly duplicated sorting functions.
| \ | ||
| external subarray : start:int -> end_:int -> t = "subarray" [@@mel.send.pipe: t]\ | ||
| external subarray : t -> start:int -> ?end_:int -> unit -> t = "subarray" [@@mel.send]\ |
There was a problem hiding this comment.
I think start is optional too: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/subarray
| end | ||
|
|
||
| open struct | ||
| module Js = Js_internal | ||
| end | ||
|
|
||
| module type S = sig |
There was a problem hiding this comment.
no idea. The way I've been handling these migrations has been to move foo2.ml to foo.ml. So this wasn't present in Js_typed_array2. I don't think we need to keep it.
d7803f7 to
4a4ec0b
Compare
part of the unification proposed in #731