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