One of biggest sources of friction with concurrency is that public structs/enums do not automatically gain Sendable conformances as do internal/private ones.
I would wager that the vast majority of apps (and developers) do not care about resiliency, ABI, library evolution, or whatever the right terminology may be here (I am sure I've used it wrong), even though a public Sendable conformance is technically a breaking change.
Let's please make the default practical and consistent for the vast majority use case.
I'm not sure it's actually the case that the majority of structs should be Sendable, though. In my opinion, attempting to fix strict concurrency diagnostics by simply adding Sendable and @MainActor annotations everywhere is bad practice and suggests a refactoring is needed.
I'm personally not a fan of that feature either, mostly from an implementation standpoint. It introduced some technical debt that hasn't been cleaned up yet.
For example, recursive enums cause request cycles now from the additional checks. We reject the following program, but we accept it if the enums become public or explicitly declare Sendable conformance:
enum A {
case a(Int, [B])
}
enum B {
case b(Int, [B])
}
I do sympathize with tricky implementation details and tech debt, but I'm not sure that's particularly important or relevant to the Swift end user here
I agree, I was just responding to your point about how to reconcile my philosophical suggestion (don't reach for Sendable by default) with reality (the existence of this feature).
My preference on the solution here is to have some notion of an internal or package conformance to Sendable for public types, so that you can still use implicit Sendable within the module where all implementation details are available, without inadvertently blocking API evolution by making that promise implicitly to clients. I also think we should do implicit Sendable inference for package declarations.
Note that this isn't about resilient libraries - implicitly inferring a public conformance to Sendable for public types would make it very easy for packages built from source to inadvertently break source compatibility for clients, such as by adding a stored property with non-Sendable type to a public struct.
Minor aside on wording
I know this was unintentional, but could you please update this to use a non-ableist word such as "make the default consistent"? This sort of language is covered by the code of conduct.
Apps in large companies (and small & medium) are typically built with many modules in a monorepo (often using something like Bazel), where all source is open and rebuilt on each build and API evolution is irrelevant. Is your proposal to make the entire monorepo one giant package here?
Not literally a Swift package in the SwiftPM sense - the boundaries of a "package" are determined by the build system with the -package-name flag. In the case where your setup is one big monorepo where all modules are always built together, your build system could define all those modules to be part of the same package. Then, if the compiler automatically inferred a package-level conformance to Sendable for public types, you'd be able to rely on it anywhere within the monorepo.
So here we'd pass -package-name AppCompany to all modules in the monorepo? Does this mean we could no longer use packages to group modules within our monorepo? I don't remember if we can pass multiple -package-name flags.