> 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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
