feat(option): better return type for Option constructors

[JalilArfaoui]

This makes some() constructor return a Some<A> and none return a None, more specific than actual Option<A>.

This enables this kind of code to work :

const updateObjectOrCreate = (
  someObject: Option<SomeType>,
  transformer: (session: SomeType) => SomeType
): option.Some<SomeType> =>
  pipe(
    someObject,
    option.getOrElse(
      constant(
        makeObject(someSaneDefaults)
      )
    ),
    transformer,
    option.some
  );

without adding à as option.Some<Session>

[samhh]

Returning specific sum members is a code smell IMO.

[JalilArfaoui]

Why is that @samhh ? I was under the idea that we want the most precise types we can have, don’t we ?

[samhh]

I've yet to come across a scenario with sum types where it's not a code smell because of an issue with code structure somewhere else. Just because we can do something doesn't mean we should.

Less esoterically this might present an issue in some spots where currently widening isn't necessary. I know this was a consideration when designing sum-types though I don't have a specific example to hand.

[asjir]

I'm afraid this might break with typescript 5.5
The reason being: define arr=T[] then typescript gives arr[i]: T even though it can be T | undefined when it's out of bounds, then the type predicate inference might give you:
O.fromNullable(arr[i]): Some<T> even though it's None if it's out of bounds

Note:
O.fromNullable has an explicit return type, so it's safe, the point is that if I had an analogous function without it in my code it could potentially break it