[swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato]

On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2th at gmx.de> wrote:

> But even outside the generated code use cases, it's nice to just be able
> to implement helpers or additional "convenience" conformances in separate
> files named appropriately (like "Type+Protocol.swift" or
> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>
> No doubt about the usefulness of having separate files with extensions here
>
> If nothing else, nested extensions could save those who actually don't
> care much about such issues from another breaking change in Swift — and
> imho it adds consistency:
> We can nest types, so why can't we nest extensions?
>
>
> Because types and extensions are quite different beasts, so something that
> applies to one doesn't necessarily apply to the other.
>
> I don't buy this argument at all without an objective explanation why the
> curly braces of extensions should be treated different than the curly
> braces of types...
>

They shouldn't be. That's why I don't support SE-0169 either, because it
would allow extensions to extend the *scope* rather than the *type*, but
only within the same file. I think that's fundamentally broken.

But my comment wasn't about curly braces—it was about types vs. extensions.
For example, you can declare local types within a function, but you can't
extend a type within a function (nor do I think it would be a good idea).



>
> I don't think that holds its weight. This feels like another case of
> "let's try to satisfy everyone who's unhappy with some part of Swift
> visibility by changing a completely different feature to make things fall
> into place", which I don't think is a sound motivation or design principle.
> The example you posted in your initial message weaves multiple
> types/nesting levels together in a way that looks *incredibly* difficult to
> follow/parse to even an experienced user of the language.
>
> Did you noticed that I started this example as mockery? In real life, I
> would hopefully never nest more than once… and do you think sprinkling
> parts of class over the project is easier to follow?
>

Depending on the type, yes. I wouldn't sprinkle the *fundamental/core*
parts of a type across the project, but if there's some kind of "aside"
functionality that doesn't depend on private knowledge of the type, then I
find it to be a nice feature to have. It requires me to have reasonable
names to my source files, but that's not a significant burden.



>
> Everyone seems to be striving for a "perfect" level of access control that
> lets individual types/members dictate precisely what other types/members
> can access them. I'm not sure if that perfection is attainable or not, but
> even if it is, I don't think it's something we should strive for. I'd
> rather have a simple visibility model that leaks a little than an air-tight
> model that allows people to write overly complicated code for the sake of
> fine-tuning access.
>
> I had no desire to change the model of Swift 2 — but apparently, others
> thought it wasn't sufficient, and I'd rather prefer a conceptually simple
> model like nesting over a complicated one with less power.
>
> Let's remember that the core team has limited resources to implement the
> things we propose, and if I have to choose between, say, serialization,
> reflection, asynchronous constructs, and rehashing visibility levels yet
> again, it's clear to me which one I would want dropped on the floor. I
> don't want perfect to be the enemy of good.
>
> Well, right now, there are several (at least one ;-) proposals that aim
> for a breaking change of the whole model… nested extensions break nothing,
> so it can be delayed for as long as the core team likes, without causing
> any trouble.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/140f50d7/attachment.html>