# Avoiding \`enum\` across \`public\` API boundaries?

**URL:** <https://forums.swift.org/t/avoiding-enum-across-public-api-boundaries/84119>\
**Category:** Discussion\
**Created:** [January 13, 2026, 8:40pm UTC](https://forums.swift.org/t/avoiding-enum-across-public-api-boundaries/84119 "2026-01-13T20:40:10Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![ExFalsoQuodlibet](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@ExFalsoQuodlibet](https://forums.swift.org/u/ExFalsoQuodlibet)\
**Post date:** [January 14, 2026, 3:05pm UTC](https://forums.swift.org/t/avoiding-enum-across-public-api-boundaries/84119/12 "2026-01-14T15:05:34Z")

</div>

> [@vanvoorden](#):
>
> This I think gets back to my question: orthogonal to the improvements that have been made to `enum` over the years to what extent is the `struct` pattern above a legit alternative that library maintainers choose to model an ADT?

I think it’s a legit pattern to use if the purpose of the library creator is to provide a type with a limited number of known constructors, but that **must not** be switched over by clients. So, basically, an enum with suppressed switching.

But I would make it even simpler, as the internal structure is irrelevant:

```swift
public struct Planet: Sendable {
  private var name: String
  
  public static let mercury: Planet = .init(name: "mercury")
  // other cases
}

```

About the idea of suppressing switchability, this unfortunately doesn’t seem to work:

```swift
@available(*, deprecated, message: "DO NOT SWITCH OVER")
func ~= (pattern: Planet, value: Planet) -> Bool {
  fatalError()
}

```

Switching over a `Planet` value doesn’t produce warnings if `Planet` is an `enum`, so it’s not really overloading the default behavior, but it does work if `Planet` is an `Equatable` `struct`.

---

_[View the full topic](https://forums.swift.org/t/avoiding-enum-across-public-api-boundaries/84119)._