Sendable types

[calvincestari]

Use case

Ensure that schema generated types, such as generated enums can conform to Sendable.

Describe the solution you'd like

More context in https://apollograph.slack.com/archives/C049FKX5N74/p1700467655099039

Original context is for generated types to conform to Sendable something like this:

// @generated
// This file was automatically generated and should not be edited.

import Apollo

public extension SomeNamespace {
  enum SomeType: String, EnumType {
    case a = "A"
    case b = "B"
    case c = "C"
  }
}

becomes..

// @generated
// This file was automatically generated and should not be edited.

import Apollo

public extension SomeNamespace {
  enum SomeType: String, EnumType, Sendable {
    case a = "A"
    case b = "B"
    case c = "C"
  }
}

[vsanthanam]

Would be curious to know if some of this can be adopted earlier than the eventual 2.0 release -- I think at the minimum the immutable generated types, as well as configuration enums like CachePolicy can add conformance without any actual implementation changes to the types themselves.

[dfed]

Is the Apollo graph slack something that external folk can join? I'd love to have a sense of where you're going with Swift Concurrency so I can design my abstractions in a future-proofed way.

[calvincestari]

Is the Apollo graph slack something that external folk can join?

Not the org internal Slack no. We do have the Apollo GraphQL Community on Discord though which has sections for clients, etc.

I'll edit the description to put the context there instead.

I'd love to have a sense of where you're going with Swift Concurrency so I can design my abstractions in a future-proofed way.

We don't have anything to share right now. It's a bunch of disconnected conversations and issues; it needs to get brought into a single document where we can talk about everything collectively.

[BrentMifsud]

Is the Apollo graph slack something that external folk can join?

Not the org internal Slack no. We do have the Apollo GraphQL Community on Discord though which has sections for clients, etc.

I'll edit the description to put the context there instead.

I'd love to have a sense of where you're going with Swift Concurrency so I can design my abstractions in a future-proofed way.

We don't have anything to share right now. It's a bunch of disconnected conversations and issues; it needs to get brought into a single document where we can talk about everything collectively.

With the recent announcement of Swift 5.10 being the last Swift 5 release, I think this needs higher priority. As we're likely going to see people using Swift 6 in their code bases starting in June with the Xcode 16 beta.