Isn’t it just a matter of following the signature and manually curry the function now that there’s no auto-currying?
let t_encode = (encoder) => (dict) => Js.Json.Object(...)
I tried but still get this fun missmatch 
Signature mismatch:
...
In module Dict:
Values do not match:
let t_encode: ('a => Js.Json.t) => t<'a> => Js.Json.t
is not included in
let t_encode: ('a => Js.Json.t) => t<'a> => Js.Json.t
well well well that’s a known issue here, long story short, there’s a bug in how the compiler displays the error and I haven’t been able to solve it yet, but meanwhile anyway, to fix the error in itself, you’d better use RescriptCore.Dict instead of Js.
Running rescript build -w with a compilation error exits with an error code, and I need to manually re-run it after every change until I get it to pass. Once passing, it goes back to restarting properly
1 Like
I’ve just created it Fix watch exiting on error by DZakh · Pull Request #6460 · rescript-lang/rescript-compiler · GitHub
4 Likes
Something has changed about @deriving(jsConverter) ?
This code works well on v10.x
It likely generates curried functions which don’t work in uncurried mode.
Oh I didn’t thought about that ! Thanks !
We just merged a fix to make the error message clearer btw
1 Like
I encountered a runtime error while migrating from ReScript version 10 to version 11, specifically with the use of uncurried functions. The issue is demonstrated in the following code snippet:
let fn = (a, b, ()) => a() + b
let a = fn(() => 1, 2, _)
When this ReScript code is compiled, it generates the following JavaScript:
// Generated by ReScript, PLEASE EDIT WITH CARE
function fn(a, b, param) {
return a() + b | 0;
}
function a() {
return fn((function () {
return 1;
}), 2, __x);
}
export {
fn ,
a ,
}
/* No side effect */
In the generated code, __x is clearly undefined, which leads to a ReferenceError at runtime. I found that replacing _ with ... in the ReScript code fixes the error. Apart from this issue, our migration to the new version is progressing without any major problems.
You can see the original code and its behavior on the ReScript playground here: ReScript Playground.
4 Likes
Sorry I haven’t had a chance to post about this since it was discovered (in July! 
) but my rescript-nodejs library isn’t really usable in uncurried mode since it leverages @obj with optional parameters. If I don’t migrate off it, uncurried mode will require all optional fields to be set which is a bit pointless. I’ve been slowly working on a branch to fix this using records.
Unfortunately it uses a sneaky trick with @obj definitions that isn’t covered by records with optional fields. Because @obj definitions are external, it opens up the opportunity to use @as to set a parameter value (and thus object property) without revealing it to the call site.
This is critical for the NodeJS Stream API, where the objectMode property completely changes the type of the stream.
The code is here, which binds to both regular and object streams, but I’ve extracted a short example to the playground:
As far as I can tell there’s no way to do this without either @obj or a wrapper function.
1 Like
It’s fixed in rc7. Should be released today or tomorrow
Not very beautiful, but it works: ReScript Playground
This solution could work without Obj.magic if we had this.
Yes, that would be the “wrapper function” option I mentioned (I was thinking a private type, but yours is a lot less code). Always an option but I’d prefer to keep this zero-cost where possible.
[edit] oh you did use a private type, it was just less obvious with the spread. I’m still not used to seeing that (and I can’t use it because I want to maintain v10 compatibility at least for a while).
Library authors will have to go through hoops to keep the libraries working for ReScript 11, 10 or even 9, unfortunately. This whole topic is also what blocks me the most on finishing the migration guide.
You could also imitate the spread and just copy all of the record fields over and leave a comment that all props need to be synced when changes happen 
1 Like
I’ll probably only keep 10; anyone still on 9 has likely chosen to for a good reason and can stick to an older library version. But I’m not going to cut anyone off and require 11 immediately.
Yes manual spread is how I will do it if I choose that path (but there’s quite a few). I doubt I’ll need a comment, the type checker should tell me if I miss anything.
there’s always the GADT solution, but I think it would only work with v11 unfortunately.
type raw
type object
type rec mode<'a> =
| @as(true) Object: mode<object>
| @as(false) Raw: mode<raw>
type stream<'a>
type rawStream = stream<raw>
type objectStream = stream<object>
type options<'mode> = {
read: (stream<'mode>, ~size: nullable<int>) => unit,
@as("objectMode")
mode: mode<'mode>,
}
@module("stream") @new
external make: options<'mode> => stream<'mode> = "Readable"
let stream = make({read: (_, ~size as _) => (), mode: Object})
The other downside is that you can’t make mode field optional.