Exactly. Worrying about implementation cost is secondary (hey, everything in the compiler is an engineering effort!) to the mess this would make of the semantics of (file)private inner aggregates.
Considering you yourself cite it being sugar, have you run into a case where this rule can be applied to, say, clean up code in a meaningful way? The given example, while visually appealing, seems awfully domain-specific. ~Robert Widmann 2016/12/06 1:03、Xiaodi Wu via swift-evolution <[email protected]> のメッセージ: > One thing to consider: > > Access modifier rules for extensions as they were revised in the Swift 3 > evolution process only work if extensions are guaranteed not to be nested, > because they assume private in the outer scope is equal to fileprivate in the > inner scope. > > (These rules differ from those for types because extensions are not > first-class entities. For a type, members default to internal but visibility > is limited by that of the containing type. For extensions, since they are not > an entity of their own, the modifier in front of the word "extension" is > merely a shorthand for the default access modifier for members contained > within, the visibility of which are limited by that of the type being > extended.) > > Furthermore, IIRC, the rules assume that extensions can never extend a nested > private type, since such a type could never be visible to an unnested > extension. > > Should nesting of extensions inside types be permitted, it would necessitate > changes to access modifier rules that did not gain consensus for review in > the Swift 3 timeline. > >> On Mon, Dec 5, 2016 at 23:34 Braeden Profile via swift-evolution >> <[email protected]> wrote: >> No special restriction here. Like I said, it’s just another way of writing >> a file-level extension within that namespace. All the functions can then be >> defined as private, public, internal, etc. as necessary. The point would be >> to define functionality for something within the right block. If I’m >> writing an entire set of types within MathEvaluator (or SelectMode, or >> whatever I’m writing), I want to be able to keep the whole file within >> MathEvaluator’s scope. I do, however, wish to write the subtypes in terms >> of “definition here, functionality there” the way extensions allow. >> >> I don’t remember a verdict from the `struct MathEvaluator.Number` syntax >> discussion. Was that shot down, or still a possibility? >> >>> On Dec 5, 2016, at 3:04 PM, Saagar Jha <[email protected]> wrote: >>> >>> How exactly would this work? Would it restrict the extension to only the >>> scope it’s defined in? >>> >>> Saagar Jha >>> >>> >>> >>>> On Dec 5, 2016, at 1:48 PM, Braeden Profile via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> I really enjoy having the ability to write and nesting my code at the >>>> appropriate indentation level in my file. Extensions are fabulous, but I >>>> wonder―solely for readability/style sake, could we allow you to properly >>>> namespace your extensions? Though I don’t know the implementation cost of >>>> this, I think it could be useful to be able to write this: >>>> >>>> class MathEvaluator >>>> { >>>> struct Number >>>> { >>>> let value: Double >>>> } >>>> >>>> struct Operation >>>> { >>>> let numbers: (Number, Number) >>>> let transform: (Double, Double) -> Double >>>> } >>>> >>>> extension Number >>>> { >>>> var factors: [Double] >>>> { >>>> // Calculate and return the factors >>>> } >>>> } >>>> } >>>> >>>> …which would be completely equivalent to: >>>> >>>> class MathEvaluator >>>> { >>>> struct Number >>>> { >>>> let value: Double >>>> } >>>> >>>> struct Operation >>>> { >>>> let numbers: (Number, Number) >>>> let transform: (Double, Double) -> Double >>>> } >>>> } >>>> >>>> extension MathEvaluator.Number >>>> { >>>> var factors: [Double] >>>> { >>>> // Calculate and return the factors >>>> } >>>> } >>>> >>>> This change is in the same ball park as this, proposed a week or two ago: >>>> >>>> struct MathEvaluator.Number >>>> { >>>> let value: Double >>>> >>>> var factors: [Double] >>>> { >>>> // Calculate and return the factors >>>> } >>>> } >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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
