Access control below public [not `protected`]

Hi @xwu , would you mind sharing the source of that quote, it would be good to know in which context Chris said that.

Personally I get the notion that Swift is not opinionated by following the evolution of Swift. Aspriational quotes are nice, but can you give some examples of opinionated decisions made since Swift Evolution started?

To me Swift Evolution is the definition of "design by committee". Even worse actually, since it is a committee of enthusiasts, not a committee of experts (as in e.g. Haskell).

1 Like

Just to make things clear, I'll re-read the threads you linked in your post and summarize the points that has been made, but that will take a few days to do so (currently super busy with work).

It is seeded by enthusiasts, but decided by experts. Remember that the Core Team always has the last word in these regards.

1 Like

I have actually tried to pitch this idea: Proposal: Eliminate the Review phase

In practice the Core Team has more of a veto power, the decisions are also made by enthusiasts.

Ah, well, fair enough.

Still, I think it doesn't inherit all of the bad traits of a design by commitee (I'll use DbC now bc it's too long) approach. The veto of the Core Team and their ability to focus the Review process on what's most relevant for the current step in the language's roadmap are clear advantages over DbC.

DbC is a low bar, though. So we should aspire to be even better than that.

I think the SE process is good in general, but the greatest weakness that I see at least is this: lack of a greater-picture design. Some things are hard to get right with a fast-paced process like SE. When you have lots of moving parts in a problem, natural SE can't effectively fix it.

I think that's how we got into the access control problems we see today. The system is dissonant with the rest of the language, and that is a consequence of the pace of SE. How can this be fixed? Well... slowly, I guess. You have to look not only at access control, but also at a possible future submodule system (whatever that means as Jordan Rose pointed out in his recent post), at what kinds of SW architecture Swift encourages (use of structs, for example), at the extensions system and what's coming for that in the future, and so on.

Problems like these are not something that can be just fixed with a proposal, and we should recognize that.

I think access control is inherently at odds with any DbC approach. The entire purpose of AC is to impose discipline on developers. While there are optimizations which can be done when there is limited visibility for a type or property, that's not why app developers want it to exist. Given that imposition of discipline is inherently subjective, you're not going to find the "One True Path" no matter how much time is spent looking.

Some simple forums searching: [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations - #43 by Chris_Lattner

1 Like

@DevAndArtist I love this (old) proposal! Any news? :smiley: What are the reasons for not having proper access modifiers in place in Swift 5?

I would really love to be able to declare my (stored)properties as private and still be able to access them inside extensions in other files. Possibly also something specific for classes and inherited but not as important.

Ugh, had to read a two-year old thread from scratch for a single new message that should have been in a new thread.

That said, is guess the solution wouldn’t be sub-modules, but a “cluster” access level that’s between “fileprivate” and “internal.” But each file in the module would have to declare which cluster it belongs to. (Plus a default void-cluster when no cluster name is given.)

1 Like

@Sajjon hi there. Well this thread was a discussion thread, not really a pitch so there is no formal proposal here buz only a back an forth of different ideas. Even though I would love to have a bit more flexibilities in the access control area which wouldn’t divide the community into multiple camps, I’m not sure if we can fix it unless we decide to do a massive source breaking change at some point.

All these existing issues and the current testability support made me change my mind a little. I no longer use private or fileprivate in any of my code. The only access modifiers I need are open (I wish it had better consistency with protocols), public and finally internal (but mostly implicitly). To signal (type/file)private access I fall back to a _ prefix.