# Multiple Types

**URL:** <https://forums.swift.org/t/multiple-types/65023>\
**Category:** Pitches\
**Created:** [May 17, 2023, 12:48am UTC](https://forums.swift.org/t/multiple-types/65023 "2023-05-17T00:48:56Z")\
**Posts on this page:** 1\
**Showing post:** 29

<div class="post-metadata">

**Author:** ![AlexanderM](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexanderm/32/9781_2.png) [@AlexanderM](https://forums.swift.org/u/AlexanderM)\
**Post date:** [May 23, 2023, 2:11pm UTC](https://forums.swift.org/t/multiple-types/65023/29 "2023-05-23T14:11:21Z")

</div>

> [@ExFalsoQuodlibet](#):
>
> It's not possible to have "sealed" protocols in Swift (like `sealed trait` in Scala or `sealed class` in Kotlin), so a protocol cannot be closed over a predeterminate number of cases (that is, conforming concrete types), like an enum does, and like an union type would do, so the use case is different.

Not quite. A type union would be more like a `@frozen enum` than an `enum`. That's the rub: when you have a public API that returns a type union, you can't add new stuff without breaking all the callers. There's times that's a perk (e.g. we don't want anyone adding new cases to `Result`), but the rest of the time it's a restriction on new API additions to the library.

That would be my objection to the `enum FieldKind` example in your linked post. You don't have a `case dateField(DateField)`, and now you can't add it (assuming your enum was public API of a library) without breaking callers. A `protocol FieldKind` would have been better.

> [@ExFalsoQuodlibet](#):
>
> About the potential utility of union types, I wrote [this post](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/52) a few years ago with some examples, in the context of discussing the possibility of adding the `Either` type to the standard library.

This is an interesting read, I think I'll need more time to mull it over!

One thing that sticks out is that the use of union types in function parameters is very much like the [flag argument anti-pattern](https://martinfowler.com/bliki/FlagArgument.html). Your function implementation ends up being one giant switch, instead of multiple tidy functions.

> [@Adding Either type to the Standard Library](https://forums.swift.org/t/adding-either-type-to-the-standard-library/36972/52):
>
> if I'm writing a library, each new public function of this kind extends the library surface.

If that were the case, then we can do the opposite and shrink the surface of every library down to a single function! All you need is this:

```swift
func fn(args: Fn1Args(...) | Fn2Args(...) | ...) -> (Fn1Result | Fn2Result | ...)

```

Switching to a flag argument doesn't decrease surface, it just obscures it. A new overload does increase surface, but no differently than adding a new member to a type union of an existing function's parameter.

---

_[View the full topic](https://forums.swift.org/t/multiple-types/65023)._