[Amendment] SE-0466 Control default actor isolation inference

Evolution Proposal Reviews
7

Since the review period of this amendment is about to finish, and the feedback was light, I'll make my position more clear:

I am against the current amendment as I understand it.

  1. I wish the proposal would be clear and explicit about the isolation of nested types:

    protocol P: SendableMetaType { }

// nonisolated
struct MyStruct: P {
  // isolation of this nested type should be
  // made explicit by the proposal.
  struct Inner { }
}

    The reason for this request is that the answer to this question is not obvious. And it's not a light one. Its consequences are quite impactful.

  2. I wish nested types would not be more isolated than their parent, unless explicitly required:

    protocol P: SendableMetaType { }

// nonisolated (proposed)
struct MyStruct: P {
  // nonisolated (my request)
  struct Inner { }

  // @MainActor
  struct Inner2: SomeMainActorIsolatedProtocol { }
}

    The reason for this request is that if a nested type is more isolated than its parent type, then it becomes painful to use:

    // nonisolated
struct MyStruct: P {
  // If this type is @MainActor…
  struct Inner { }

  // nonisolated
  func myMethod() {
    // … then it can't be used in a nonisolated method 👎
    let inner = Inner()
  }
}

  3. I wish that a protocol that inherits SendableMetatype would suppress the default global-actor isolation when the conformance is declared in the same file as the definition of the conforming type:

    protocol P: SendableMetaType { }

// nonisolated (proposed)
struct S1: P { }

// nonisolated (my request) - @MainActor (proposed)
struct S2 { }
extension S2: P { }

// @MainActor
struct S3 { }

    The reasons for this request are:

    • There are a lot of precedents in the language.
    • A lot of prominent and influential Swift developers and coding styles favor and foster the use of extensions for declaring conformances. This is a very frequent practice, especially when the protocol has requirements. In this regard, the CodingKey protocol which is used as an example in the amendment is an exception. It is not CodingKey that should inform the design of the amendment.

  4. If the language would ship without point 2. and 3. above, then introducing them later (due to the foreseeable feedback I have described) would be a breaking change.

    We'd need an experimental/future language flag, an Xcode option, etc. It would be quite costly, not only for compiler engineers (not my direct concern, I agree), but also for library authors, who would have to write painfully precise documentation for the users of those libraries. Please remember that unlike the stdlib, third-party libraries frequently want to target several Swift versions.

    That's why I insist on the problems created by their absence: they can be avoided, now.

I hope @Douglas_Gregor finds my requests sufficiently grounded.

11 Likes