No, I personally haven’t found a use case besides aesthetics. The whole access
level situation never even crossed my mind, originally, and they do become
terribly confusing in this case.
I would appreciate the resolution of a bug that makes this syntax unnecessarily
appealing:
struct A
{
struct B
{
struct C
{
}
}
}
extension A.B.C
{
var foo: C { } //error: unidentified type C
var bar: B.C { } //error: type B doesn’t have a subtype C
var faz: A.B.C { } // fine (yet wordy), given an implementation.
}
> On Dec 6, 2016, at 4:55 PM, Robert Widmann <[email protected]> wrote:
>
> 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]
> <mailto:[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] <mailto:[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]
>>> <mailto:[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] <mailto:[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] <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] <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
