Swap Either type params

[mikearnaldi]

Swap type params of Either from Either<E, A> to Either<R, L = never>.

Along the same line of the other changes this allows to shorten the most common types such as:

import { Either } from "effect";

const right: Either.Either<string> = Either.right("ok");

While it was confusing to use Either<A, E> I don't find it particularly confusing to use Either<R, L>, the type reads like "it's either a right or a left"

[changeset-bot]

🦋 Changeset detected

Latest commit: e54a577

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages

Name	Type
@effect/platform-node-shared	Major
@effect/typeclass	Major
effect	Minor
@effect/schema	Major
@effect/cli	Major
@effect/platform-bun	Major
@effect/platform-node	Major
@effect/printer-ansi	Major
@effect/printer	Major
@effect/experimental	Major
@effect/opentelemetry	Major
@effect/platform-browser	Major
@effect/platform	Major
@effect/rpc-http	Major
@effect/rpc	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ethanniser]

I think this a good change to keep it in line with all of the other changed types

But I am curious why the decision to only modify the type parameter order, and not the runtime semantics?

Surely the function named Either.right would result in a Either with the type of the right?

const right: Either.Either<string, never> = Either.right("ok"); // right = left
const left: Either.Either<never, number> = Either.left(5); // left = right

because Either is "just a tagged union" there shouldn't be any reason that 'right' belongs to the first type parameter any more than left

making them match just feels nicer?

of course it makes it a bit of a bigger migration, but its already a breaking change

[mikearnaldi]

I think this a good change to keep it in line with all of the other changed types

But I am curious why the decision to only modify the type parameter order, and not the runtime semantics?

Surely the function named Either.right would result in a Either with the type of the right?

const right: Either.Either<string, never> = Either.right("ok"); // right = left
const left: Either.Either<never, number> = Either.left(5); // left = right

because Either is "just a tagged union" there shouldn't be any reason that 'right' belongs to the first type parameter any more than left

making them match just feels nicer?

of course it makes it a bit of a bigger migration, but its already a breaking change

Users complained that "right" feels like "success" and "left" doesn't , also we couldn't write a codemod for that as it touches too many things that are contextual so the pain would probably be too big to migrate manually

[patroza]

gj for swapping to more semantic L and R. Use Effect/Exit when you need to model Error and Success.
there's still the obvious swapping in the generics: Right is on the Left and Left is on the Right.
but that's alright

[datner]

I think it should be noted in the docs, otherwise we will have fp devotees knocking at the door

[mikearnaldi]

I think it should be noted in the docs, otherwise we will have fp devotees knocking at the door

they can keep believing their cult and use fp-ts v2 :) jokes aside, yes everything needs to be documented

[samhh]

I'm late to the party on this, but does this not make any prospective migration from fp-ts more difficult? If so, is it really worth it?

[mikearnaldi]

I'm late to the party on this, but does this not make any prospective migration from fp-ts more difficult? If so, is it really worth it?

We are not optimizing for fp-ts migration, we are optimizing for newcomers and effect users.o

The migration from fp-ts is a much larger topic, in fp-ts Either was used as a Result, in Effect results are expressed as Exit and also 90% of the direct Either usages should probably instead be straight Effect usages.