I have not voted in favor or against the proposal. I have been reading a lot of responses but I agree with Tony.
When I started reading the proposal everything was more or less fine half way through the proposal because it was reverting private to fileprivate between the type and its extensions within the same file. I said, if you think of the type and its extensions as a unit then it makes sense. I can explain that. Then it started describing a different behavior among the extensions located in a file separate from the file containing the definition of the type. That just started a whole debate inside my head and I understand the passionate responses on both sides. But then I imagined myself explaining this to someone new to Swift and it just doesn't seem right. If it becomes convoluted then that's a red flag that it does not belong in Swift. I agree fileprivate may be ugly to some and it may be more popular than private. But I think fileprivate is very clear. I know what it does from its name without having to ask. And private behaves the way private works in other languages. Regards > On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@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. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
