You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using t.intersection, the correctness of the types/behavior is affected by the order of the codecs in the array.
Current Behavior
I get no type error in circumstances in which the code fails at runtime (see the example below).
Expected behavior
I expected that if it's intentional that the order of elements in intersection is meaningful, that would be reflected in the types, or if it isn't, that the order of arguments wouldn't matter in runtime behavior.
Reproducible example
import*asEfrom"fp-ts/Either";import{pipe}from"fp-ts/function";import*asOfrom"fp-ts/Option";import*astfrom"io-ts";import{DateFromUnixTime,optionFromNullable}from"io-ts-types";describe("bug with types",()=>{it("infers types incorrectly",()=>{constSomeCodec=t.intersection([t.type({date: optionFromNullable(DateFromUnixTime)}),t.record(t.string,optionFromNullable(t.unknown)),]);constresult=SomeCodec.decode({date: 367722000,dog: "cat"});// No type error but it throwsexpect(()=>pipe(result,E.map(({ date })=>pipe(date,// `d` isn't actually a date here. It's a number (like the input)O.map((d)=>d.toISOString()))))).toThrow(TypeError);});it("infers types correctly with a different order",()=>{constSomeCodec=t.intersection([// Move this upt.record(t.string,optionFromNullable(t.unknown)),t.type({date: optionFromNullable(DateFromUnixTime)}),]);constresult=SomeCodec.decode({date: 367722000,dog: "cat"});expect(()=>pipe(result,E.map(({ date })=>pipe(date,O.map((d)=>d.toISOString()))))).not.toThrow(TypeError);});it("infers types correctly without `optionFromNullable`",()=>{constSomeCodec=t.intersection([t.type({date: optionFromNullable(DateFromUnixTime)}),t.record(t.string,t.unknown),]);constresult=SomeCodec.decode({date: 367722000,dog: "cat"});expect(()=>pipe(result,E.map(({ date })=>pipe(date,O.map((d)=>d.toISOString()))))).not.toThrow(TypeError);});});
Suggested solution(s)
I suspect there is some kind of unintended effect of ordering in intersection.
Your environment
I just wrote the code that does this today so haven't seen it fail or succeed with other io-ts versions.
Software
Version(s)
io-ts
2.2.20
fp-ts
2.13.1
io-ts-types
0.5.19
TypeScript
4.7.4
The text was updated successfully, but these errors were encountered:
🐛 Bug report
When using
t.intersection
, the correctness of the types/behavior is affected by the order of the codecs in the array.Current Behavior
I get no type error in circumstances in which the code fails at runtime (see the example below).
Expected behavior
I expected that if it's intentional that the order of elements in
intersection
is meaningful, that would be reflected in the types, or if it isn't, that the order of arguments wouldn't matter in runtime behavior.Reproducible example
Suggested solution(s)
I suspect there is some kind of unintended effect of ordering in
intersection
.Your environment
I just wrote the code that does this today so haven't seen it fail or succeed with other
io-ts
versions.The text was updated successfully, but these errors were encountered: