> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution > <[email protected]> wrote: > > Sent from my iPhone > On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution > <[email protected] <mailto:[email protected]>> 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? 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 >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> >>> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <[email protected] >>> <mailto:[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... >>> >>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
