SE-0404: Allow Protocols to be Nested in Non-Generic Contexts

Biggest +1 I think I’ve ever given. Holly and Karl may now be my favourite people in the world (especially given the future direction of allowing types to be nested in protocols)!

3 Likes

@hborla Perhaps it would be nice to have a dedicated voting post in proposal reviews, allowing people to unleash their "+1" energy? just a thought

Now to the point of the proposal: one additional future direction could be to introduce into the language a way to define a namespace without defining a new type (not protocol/struct/class/enum/actor).
At its simplest, this could be C++-style namespaces. A more sophisticated option would be a type-like entity whose members are all implicitly static.

protocol MyProtocol {
  static var foo: Int { get }
  static func bar() -> String
}

a_fancy_keyword_like_namespace MyScope: MyProtocol {
  let foo: Int = ...
  func bar() -> String { ... }
}

More or less corresponds to what is now expressed through enums without cases:

enum MyScope: MyProtocol {
  static let foo: Int = ...
  static func bar() -> String { ... }
}

This is not a super-important feature, since it can already be expressed in the language. However, I find it strange to have a pattern that forces you to declare enums without cases.

1 Like

LGTM, this is definitely a worthwhile addition to Swift. It is something I've really missed when coming to Swift all the years ago and still often bump into missing it.

I'd also definitely welcome the future direction to allow Sequence<T>.Iterator where Iterator is the nested protocol inside the Sequence. It's fine to leave this to future proposals -- although I hope they will come sooner than later :slightly_smiling_face:

3 Likes

might be getting a bit ahead of myself, but what are the chances of this making it into the 5.9 release?

As per Ben's post re: the 5.9 release process, only "major showstoppers" are eligible for being picked onto the 5.9 branch at this point.

3 Likes

I think including a poll would reinforce the misconception that Swift evolution reviews are votes. It's also very helpful for reviewers to briefly elaborate why they're giving the +1, even if it's just a sentence, and a poll would encourage people to not leave a review comment with their elaboration. But I don't see this as a problem; "+1" comments are welcome!

15 Likes

Ok, noted. +1 then

Thanks everyone for participating in this review! SE-0404 has been accepted.

Holly Borla
Review Manager

10 Likes

I do like this feature. It’s so frustrating to have to think First Level since every thing can be Inner-ed.

1 Like

I reckon that also holds for point-releases? If so, then too bad that we have to wait until 5.10 to use this wart-removal.

Given the implementation of SE-0404 has not landed on main because it isn't yet complete, it is premature to discuss which release of Swift the feature will land in.