[swift-evolution] Enhancing access levels without breaking changes

[Tony Allevato]

On Mon, Apr 10, 2017 at 8:26 AM Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

> I’m not sure that this solves anything meaningful (whether in relation to
> SE-0169 or more generally), does it? What advantage does this provide over
> just declaring the protocol conformance and those methods as a direct part
> of the parent type? This seems like it would just introduce more
> indentation, and more lines of code, for zero benefit.
>
> Well, I'm not overwhelmingly convinced of this whole "we put same-module
> stuff into extensions" anyways, so it's debatable wether proposals like
> SE-0169 have any meaningful effects at all… do you think that conformances
> in same-file extensions have a real benefit?
>

Yes—as Matthew already stated, it's mostly organizational, but the
flexibility is nice to have. I like being able to group functionality of a
type not solely within a single set of curly braces or a single file, but
sometimes also into separate files if the situation calls for it.

For example, in Swift protocol buffers we have a handful of types that are
called "well-known types" that are generated from their .proto file, but to
which we also add a number of convenience initializers/methods. Since the
type itself is generated, extensions in separate files let us do this
without having to hack the generator with special cases to inline the code
into the same file.

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.



> 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. Nesting extensions
as you described would seem to be not much different than just flattening
the extension's contents into the type directly or moving them out to
file-level, with the only difference being that it adds a new scope for the
purposes of visibility or getting something like "friend" in C++ (but your
example is even more fine-grained than that).

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.

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.

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.



> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/8a6c7ebd/attachment.html>