[swift-evolution] access control proposal

[Brent Royal-Gordon]

> Do you really see no value in completely hiding implementation details of an API and making it enforceable by the compiler?

On the contrary, I see great value in hiding implementation details. But, as I’ve previously explained, I don’t think adding a slew of different levels of access is the answer here. In many cases where `local` appears to be valuable, the real problem is that several concerns are being mixed together. That’s what’s wrong in the _queue/_children case: the concern of synchronizing access to _children has been improperly mixed with the concern of actually manipulating the _children array. Only by properly separating those concerns can you actually prevent bugs when accessing _children—and that separation is easily achieved with a separate file and `private`.

I’ve seen you make this argument several times:

> If you were writing a book, would you want to put every paragraph into a separate file?


But that’s not what we’re actually contemplating here. A software project is a bit like an encyclopedia. Each article covers one subject, and not all subjects are the same. Some articles are short; some are long. But you would never glom several short articles together if they were about different subjects.

Similarly, each file in a project should handle one concern. And it is concerns—not types, not scopes—which have implementation details that should be hidden from the outside world. Almost by definition, if there’s something in one part of a file that shouldn’t be accessed by another part, those two don’t belong in the same file. It doesn’t matter if some of the resulting files are only ten lines—you’re not going to run out of inode numbers, are you?

-- 
Brent Royal-Gordon
Architechies