produce function return type is narrow type of base when using const assertions

[Juani Garay]

🐛 Bug Report

Consider an object with a field "myNum" with a number 7 assigned to it. Suppose this object is read-only and you use a const assertion on it. If you were to produce a different object from it, applying the '++' operator to myNum, you'd expect the produced object to have myNum of type number or 8. But it is still 7.

Link to repro

Here you go.

To Reproduce

Steps to reproduce the behavior:

Perform a const assertion over an object, and then produce a new object mutating some of its values.

Observed behavior

The produced type indicates that the value is the former

Expected behavior

The produced type should indicate that the value is the latter: the value observed at runtime.

Environment

We only accept bug reports against the latest Immer version.

• Immer version:
• I filed this report against the latest version of Immer
• Occurs with setUseProxies(true)
• Occurs with setUseProxies(false) (ES5 only)

[Michel Weststrate]

It is not possible to produce a new output type based on the input type + parsing what your code actually does, so you'll either have to widen the type, or cast yourself to a better one.

…

On Fri, Oct 7, 2022 at 12:39 AM Juani Garay ***@***.***> wrote: 🐛 Bug Report Consider an object with a field "myNum" with a number 7 assigned to it. Suppose this object is read-only and you use a const assertion on it. If you were to produce a different object from it, applying the '++' operator to myNum, you'd expect the produced object to have myNum of type number or 8. But it is still 7. Link to repro Here you go. <https://codesandbox.io/s/immer-sandbox-forked-c3zep2?file=/src/index.ts> To Reproduce Steps to reproduce the behavior: Perform a const assertion over an object, and then produce a new object mutating some of its values. Observed behavior The produced type indicates that the value is the former Expected behavior The produced type should indicate that the value is the latter: the value observed at runtime. Environment We only accept bug reports against the latest Immer version. - *Immer version:* - I filed this report against the *latest* version of Immer - [X ] Occurs with setUseProxies(true) - [X ] Occurs with setUseProxies(false) (ES5 only) — Reply to this email directly, view it on GitHub <#982>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBDUCUUV5FLL5DUOV6DWB5PMDANCNFSM6AAAAAAQ7DF5P4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Juani Garay]

@mweststrate

Yes, that would be a workaround for my specific case. To me, this is a weird behavior for a library I use. Is this the intended behavior?

I've done some digging and it seems to be possible to widen some input types in case it's not. See here. Maybe with a little tinkering I can manage to make produce return a Wide<Base> instead of Base. But I need to know if this is the intended behavior before I start working on a PR.

[Michel Weststrate]

Yeah, but that'd break things like enumerations etc. I think what is happening here is the confusing conceptually the type of a thing versus a concrete instance of a thing. Immer always takes an instance of a type, and changes it into the another instance of the same type. So your type should be wide enough to capture both input and output, rather than be two conceptually (typewise) different things. In your example, make the increment parameterisazable, and you'd see it'd fall very quickly apart if you want to capture that in the type system.

…

Message ID: ***@***.***>

[Juani Garay]

Maybe I worded this badly. I believe that the return type of a function should match the instances that it outputs. Hence the example where the value is 8 but the type is 7.

I hadn't considered enums, they would break if the types were widened. In any case, if the expectation is that we should simply pass wider types to avoid incongruent outputs I won't look into it. Thanks for your replies.