[swift-evolution] Enhancing access levels without breaking changes

[Tino Heth]

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

> 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?

> 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/dac0b92e/attachment.html>