Does Arrow facilitate sugar syntax patterns for mu...

# arrow

[Darryl Miles]

Does Arrow facilitate sugar syntax patterns for multiple named types for return values ? I think these maybe similar to Union types.
I am looking for a high-level abstraction that can support returns types like FirstType | SecondType | ErrorType so that for example a swagger/OpenAPI/REST highlevel client side API can support decoding the response payload and hydrating a concrete class type from a known-ahead-of-time list of possible classes.
The Either[] pattern of category theory is good for the error-channel use case.

FWIW ideally I would like the top level API to be scriptable (if needed) to manage sugaring the interface so it just works with duck typing, but the implementation below does not need to be like this, the whole point is the API the user consumes hides verbose boilerplate constructs. So I am just trying to evaluation options for the cross over between.
At the moment I have Tuple() like arrangement: return Triple(o as? FirstType, o as? SecondType, errorType) so am expecting to manage this at the scripting layer.

So the question is "are there any useful constructs within Arrow to consider in this area of Union types?" a single return value that can be one of a fixed list of known types.

[Alejandro Serrano.Mena]

there's nothing for (unnamed) union types in Arrow

[Alejandro Serrano.Mena]

it was announced this year in KotlinConf that partial support for union types for errors may come to the language, though

[Darryl Miles]

Thanks for the reply and confirmation.

Now you remind me I did see/hear about Kotlin ecosystem getting support in this area hence why I'm studying all available options, Arrow has a use for very high-level API composition as well.