> On Apr 10, 2017, at 9:49 AM, Tino Heth via swift-evolution > <[email protected]> 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… Extensions are not Partials. > >> 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? Extensions are not Partials. > >> 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. Partials limited to the same scope can do the same with out having to give extension special nesting powers :) > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
