[Idea] Extending syntax for `extension`

Evolution Discussion
1

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
  }
}

2

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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

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 <saagar@saagarjha.com> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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 < swift-evolution@swift.org> 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 <saagar@saagarjha.com> 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 < > swift-evolution@swift.org> 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
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

5

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 <swift-evolution@swift.org> のメッセージ:

···

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 <swift-evolution@swift.org> 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 <saagar@saagarjha.com> 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 <swift-evolution@swift.org> 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
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

6

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 <devteam.codafi@gmail.com> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:

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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <saagar@saagarjha.com <mailto:saagar@saagarjha.com>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution