Add explicit Sendable unavailability and add missing Sendable conformances
#2578
Conversation
…formances Found with `-require-explicit-sendable` compiler flag. We may want to enable this flag in CI but it currently warns also for internal types that are @usableFromInline but we could mark them explicitly as well if we wanted.
| @@ -147,7 +147,7 @@ public struct NIOAsyncWriter< | |||
| /// This struct contains two properties: | |||
| /// 1. The ``sink`` which should be retained by the consumer and is used to set the writability. | |||
| /// 2. The ``writer`` which is the actual ``NIOAsyncWriter`` and should be passed to the producer. | |||
| public struct NewWriter { | |||
| public struct NewWriter: @unchecked Sendable { | |||
There was a problem hiding this comment.
Unsure about that one the Sink is not Sendable right now because we expect it to be only held in one isolation domain at any given time even though it is fully thread-safe. We certainly can't make this type unchecked Sendable then. So we either make the Sink Sendable as well or don't make this one Sendable
| @@ -93,7 +93,7 @@ let SO_TIMESTAMP = CNIOLinux_SO_TIMESTAMP | |||
| let SO_RCVTIMEO = CNIOLinux_SO_RCVTIMEO | |||
| #endif | |||
|
|
|||
| public enum NIOBSDSocket { | |||
| public enum NIOBSDSocket: Sendable{ | |||
There was a problem hiding this comment.
I don't think we can make a socket Sendable it is the same as FileHandle
There was a problem hiding this comment.
Ah good catch. Then my comments from below apply. Should we really make namespaces Sendable?
There was a problem hiding this comment.
I can't see any reason to do so.
| @@ -378,7 +378,7 @@ extension ChannelError: Equatable { } | |||
| /// The removal of a `ChannelHandler` using `ChannelPipeline.removeHandler` has been attempted more than once. | |||
| public struct NIOAttemptedToRemoveHandlerMultipleTimesError: Error {} | |||
|
|
|||
| public enum DatagramChannelError { | |||
| public enum DatagramChannelError: Sendable { | |||
There was a problem hiding this comment.
This is just a namespace right? We probably shouldn't make it Sendable right now
There was a problem hiding this comment.
Okay, I will mark it then as non-sendable. I don't think it really matters though.
| @@ -64,7 +64,7 @@ public typealias ConnectTimeoutOption = ChannelOptions.Types.ConnectTimeoutOptio | |||
| public typealias AllowRemoteHalfClosureOption = ChannelOptions.Types.AllowRemoteHalfClosureOption | |||
|
|
|||
| extension ChannelOptions { | |||
| public enum Types { | |||
| public enum Types: Sendable { | |||
There was a problem hiding this comment.
Same here. This is just a namespace right?
|
@FranzBusch eventually everything is either Sendable or not Sendable. We have this grey zone right now where the diagnostics severity is influenced by explicit or implicit marking but in Swift 6 mode this should no longer be the case. |
I am unsure if that's true. In my head there are three distinct constraints |
I think this is fundamentally not true. Uninhabited types are neither Sendable nor not Sendable. They can certainly conform, but as a practical semantic matter they aren't Sendable or not Sendable because no values of them exist. Similarly, |
I can't follow. You say yourself that The only way a Type can "maybe" conform to a Protocol is through retroactive conformance. However, this isn't relevant as Sendable is a marker protocol and is checked at compile time only. Generics are another possible case where the concrete type might conform to Sendable but as Sendable is only checked at compile time this doesn't matter either. |
|
I'm not saying uninhabited types can't conform to Similarly, This is why it's simply not worth arguing about whether they conform or not: their conformance is meaningless, and no correct code could possibly rely on it. |
Found with
-require-explicit-sendablecompiler flag. We may want to enable this flag in CI but it currently warns also for internal types that are @usableFromInline but we could mark them explicitly as well if we wanted.