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

austintatious · 2023-07-25T14:35:33.478Z

+1 I would love to be done with writing typealiases just to achieve similar outcomes.

ajo · 2023-07-25T18:28:12.364Z

+1

I’ve missed scoping protocols many, many times. A consequence of not having this is that protocol names are longer than necessary and at the same time less clear. A big gap in Swift is filled by this proposal.

Hopefully the standard library can be revised with this in mind for Swift 6.

A quick reading.

Josh_Osborne · 2023-07-25T19:13:41.935Z

Strong +1.

My only reservation is the non-generic scope limit, but I'm assuming supporting generic scopes would complicate the implementation enough to miss the next Swift train out of the station.

I hope in the future we can revisit generic scope support.

jaredgrubb · 2023-07-25T21:26:48.353Z

+1. I have long been annoyed that this doesn't work, mainly for namespacing reasons.

aggie33 · 2023-07-26T00:18:31.045Z

+1 on this proposal

I think that generic protocols would be really cool and useful, and if they were added it feels like it could be simple to add support for generic contexts.

taylorswift · 2023-07-27T23:08:32.369Z

i wrote up the following intending for it to be a starting point for discussing a new language feature, but as i was finishing it i realized it was really more of an argument for why this proposal should pass.

in C++, i always spent (wasted?) a lot of time thinking about memory safety.

in swift i find that i spend (waste?) a lot of time thinking about lexical hierarchy.

here’s an example of a hypothetical library product that vends one single overwhelmingly important type, and a supporting protocol to be used with that type:
struct Barbie
{
    enum ID {}
    struct Instant {}
    struct Camera<Film> where Film:BarbieFilm 
    {
        struct Photo {}
    }
    ...
}
protocol BarbieFilm
{
    var id:Barbie.ID { get }
    var timestamp:Barbie.Instant { get }
}
i say product and not module because putting both of these definitions in the same module precludes using Barbie as a module name. and in light of that i think it’s helpful to list what i think are some reasonable goals regarding the usability of a library product:

a module’s name should be a description of what the module contains, and not a description of the fact that it is a module. so we really want to use this library as import Barbie and not import BarbieFramework.

library consumers should standardize on one import spelling. in other words, if there is a module named Barbie, but most of the library’s critical functionality is actually @_exported from an umbrella module like BarbieFramework, and import BarbieFramework is the prescribed way to consume the library, we do not want people to type import Barbie and then wonder why nothing is working.

this is also a way of restating goal #1, if the “public-facing” umbrella module has the simplest name amongst its constituent targets, no one will accidentally import a component of the library when they mean to import the whole thing. (think NIO vs NIOCore.)

library API should obey namespace shadowing rules. in swift, this means if you have a module named Barbie and it also has a top-level type named Barbie, then every other (public) type vended by that module must be lexically scoped to Barbie. things that cannot be nested (like protocols) need to be @_exported from another module with a different name.

library consumers should never utter an internal module name. this is just another way of saying that library consumers should not have to care about a library’s internal dependency graph, and they should not care what module a type is “really defined in”.

at the pure source code level, this is an equivalent statement to “your library should have a very low probability of name collisions with other code”, because if you never experience a name collision, then you never have to qualify a reference with a module name in the first place.

and yet “what module a type is actually defined in” is kind of unescapable, it shows up in URLs, it shows up in symbol links, and people get it wrong all the time. so even if you have the most well-designed lexical structure possible, a naming scheme so holy that it will never collide with anyone else’s names, you still have to care about what your inner modules are named, you can’t just prefix them all with underscores.

anyway, i was originally envisioning some kind of “public-facing module name feature”, but then i realized these “usability principles” are really just an elaborate mitigation strategy for the problem described in goal #3: if it weren’t for the fact that we need to reexport protocols from hidden modules with @_exported because they cannot live in the the user-facing module, then we don’t need to lower the rest of the module’s implementation into a hidden sibling module, in fact we can really dispense with the whole “hidden modules” nonsense entirely.

i for one can’t wait for the day where i can stop obsessing about module naming because i will finally be able to declare a protocol in the same module as the code that uses it.

mergesort · 2023-07-28T01:55:18.512Z

One of the rare times I chime in on the forums but I want this so badly that I felt the need to say +1 +1 +1 would absolutely love to see this.

JohnEstropia · 2023-07-28T04:51:15.093Z

+1
Whatever argument there is against this feature is moot because you can already bypass this restriction:

protocol _SomeProtocol {}

enum Namespace {
    typealias SomeProtocol = _SomeProtocol
}

This update just lets us declare Namespace.SomeProtocol directly without going through the hoops

Alan · 2023-07-28T21:43:32.216Z

+1

Long have we suffered excess identifier noise

pilky · 2023-08-01T10:56:41.060Z

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)!

dmt · 2023-08-01T12:54:16.934Z

@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.

ktoso · 2023-08-07T09:32:55.113Z

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

taylorswift · 2023-08-07T16:08:18.490Z

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

Jumhyn · 2023-08-07T16:12:37.506Z

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.

hborla · 2023-08-08T15:59:12.581Z

dmt:

@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

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!

dmt · 2023-08-08T16:00:55.182Z

Ok, noted. +1 then

hborla · 2023-08-09T04:57:29.114Z

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

[Accepted] SE-0404: Allow Protocols to be Nested in Non-Generic Contexts Announcements

Hello, Swift community! The review of SE-0404: Allow Protocols to be Nested in Non-Generic Contexts ended on August 7th. Feedback was quite positive, with many reviewers eager to use nested protocols. Several reviewers noted that they hope protocols nested in generic contexts are explored in the future, and nothing in this proposal precludes that direction. The Language Steering Group has decided to accept the proposal. Thank you to everyone who participated in the pitch and proposal review! Y…

Holly Borla
Review Manager

Luc-Oivier · 2023-09-06T18:21:31.123Z

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

mickeyl · 2023-09-19T15:21:43.150Z

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.

hborla · 2023-09-19T20:32:24.188Z

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.