So, currently, there is no option for if I want to define that an Interface method should return eit...

# getting-started

[gabrielfv]

So, currently, there is no option for if I want to define that an Interface method should return either one class or some other, right? Type composition like:

typealias SourceOrFactory<T> = List<T> | DataSource.Factory<T>

[codyoss]

I don’t think so. Think you would have to do use a generic container and use something like when to check the type

[gabrielfv]

Doesn't sound like a great approach. The kind of compile-time check for that isn't really good if even possible.

[Luke]

Maybe you can use sealed classes

[Andreas Sinz]

how would the compile-time checks look like for your example?

[gabrielfv]

For example, if a method was to return SourceOrFactory<T>, if I tried to override it returning something that wasn't either List<T> or DataSource.Factory<T> it could be caught as an error.

[gabrielfv]

It is as simple as any compile-time type checking, only difference being it would match for more than one type.

[Andreas Sinz]

the closest you can get there is by using a sealed class

[gabrielfv]

Yes, indeed. Not as good as I will need to define wrappers for the classes, but works.

[karelpeeters]

This is also implemented in #arrow by the Either class.

[gabrielfv]

Would you believe if I told you I was looking at it right now?

[gabrielfv]

Actually, was reading about Validated and Ior currently

[gabrielfv]

Not enough to make me want to add a dependency, but Arrow seems very interesting overall

[karelpeeters]

Haha that's exactly my feeling about it.

[maxmello]

What would be a good practice use case for this "Either" behavior? Intuitively sounds like an anti pattern to me..

[karelpeeters]

Error handling without exceptions: Either<Result, Error>

[maxmello]

Ok yeah that makes sense, thanks

[karelpeeters]

You could say nullability is an example of this too, T? == Either<T, Unit>