Bad Typing Ok / Error about ts-belt HOT 6 OPEN

+1 for this.
with ts-pattern, I always use { TAG:0 } instead of { __:'OK' }, which leads poor readability.

from ts-belt.

to solve the problem I mentioned i have created :

export const Left = <T>(error: T): Error<T> => {
  return {
    TAG: 1,
    _0: "data",
    __: "Error",
  };
};

export const Right = <T>(value: T): Ok<T> => {
  return {
    TAG: 0,
    _0: "data",
    __: "Ok",
  };
};

=> so object and type are identical

and in my eslint I have forbidden the use of Ok and Error function :

"no-restricted-syntax": [
      "error",
      {
        "selector": "CallExpression[callee.name='Error']",
        "message": "Error is deprecated, use Left instead because it complies the full type Error of the lib ts-belt.  "
      },
      {
        "selector": "CallExpression[callee.name='Ok']",
        "message": "Ok is deprecated, use Right instead because it complies the full type Ok of the lib ts-belt.  "
      },
]

from ts-belt.

those __:'Ok' | 'Error' s are not belt(the core of this library)'s part. It's added by author @mobily's. It could be cumbersome to match all belt functions to work with __ fields. I'd still recommend using TAG : 0 | 1 field, which could be easily reminded from exit code. Rescript's internal functions use TAG field.

from ts-belt.

@mobily I would like to draw your attention to this very important issue.

Since this library is based on typescript and moreover on functional programming, it is very important that the types and implementation match.

thank you in advance

from ts-belt.

@JUSTIVE Okay, I get the point!

The only potential problem would be if someone used a library or coded something with the same structure, then there would be a conflict.

I mean anything that uses a structure with : TAG : 0 | 1

The best way to avoid this would be to have a key like: BELT_TAG instead of TAG or an other key showing this structure is from ts-belt

-> Of course, I'm aware that this type of conflict may be rare, but I like to use the safest code :)

from ts-belt.

I see the concerns you have. But I think It's quite a rare to have such type, names.
would be great to adopt your suggestion. I'll make a PR for that, but It'll break codes worked with previous versions.

from ts-belt.