> On 11 Apr 2017, at 09:40, John McCall <rjmcc...@apple.com> wrote: > >> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Sent from my iPhone >> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> 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 understand what you are saying and I wouldn't be against relaxing that >> requirement (not talking for Chris here). >> >> The model would change from "Types share scopes with their extensions in the >> same file the type was defined" to "Types and their extensions share the >> same scope in each file". > > Oh, I had missed that somehow. I agree that that is a very strange rule. Do > you know why it was proposed that way?
We had to take a stance and Chris seemed to prefer the rule that was proposed. I didn't press because I'm sure he has reasons for preferring it that way. But I have a preference for generalizing visibility to all extensions, even to those in a different file than the type. > John. > >> >>> 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 >> _______________________________________________ >> 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
