[swift-evolution] Proposal: Allow "flat" declaration of nested types

[Rien]

Sure you can do that, but I rather write:

struct A.B {…}

than

extension A { struct B {…} }

The first seems much “swiftier” to me.
In fact, now that this “obvious” dot-notation has been pointed out, I wonder why this was not the initial implementation instead of the “extension” keyword.
Was the dot-notation considered? and if so, what was the rationale for choosing the “extension” keyword? Is it worth reconsidering?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 20 Nov 2016, at 19:05, Derrick Ho <wh1pch81n at gmail.com> wrote:
> 
> Alexander, I took your code and "flattened" it with what currently exists in Swift 3.  Is this not flat enough for you?
> 
> struct A {
>    var a = 0
> }
> 
> extension A {
>    struct B {
>       var b = "Bee"
>    }
> }
> 
> extension A.B {
>    struct C {
>       var c = 0
>       func someFunc() {
>          print("something")
>       }
>    }
> }
> 
> A().a // print 0
> A.B().b // Print "Bee"
> A.B.C().someFunc() // Print "something"
> 
> 
> 
> On Sun, Nov 20, 2016 at 10:23 AM Alexander Doloz via swift-evolution <swift-evolution at swift.org> wrote:
> About scope visibility rules – I think, for now this new syntax should behave exactly like the old. What’s possible with old syntax should be possible with the new and vice versa.
> To Robert Widmann’s question about real situation where such syntax will be useful – right now I have a project where nested types are used. They are good for my situation, but:
> 1. When they appear directly in the outer type I have to take extra effort to distinguish between properties and methods of outer type vs. properties and methods of inner type.
> 2. And yes, indents. I don’t do something crazy - I have only I place where 3 types are nested. But even if there are 2 types, it becomes inconvenient to read code in the methods of the last nested type.
> New syntax solves this issues.
> > 20 нояб. 2016 г., в 16:00, Rien <Rien at Balancingrock.nl> написал(а):
> >
> > Imo, it does not need extreme nested code to be useful. I find that more than 1 level of nesting tends to create obfuscation. Probably because we loose the ability to associate type C with type A. By allowing "struct A.B.C" it is very clear that C does indeed depend on A.
> > However, I can already see questions coming: how to refer to struct A elements and can we introduce new scope visibility rules?
> > Still, I like this way of programming, so for me its a +1
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Swiftrien
> > Project: http://swiftfire.nl
> >
> >
> >
> >
> >> On 20 Nov 2016, at 04:18, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
> >>
> >> I think this is an interesting proposal, but I don't write enough extremely-nested code to know that it will do much more than save you some whitespace - as you say.  What situation have you run into specifically where this kind of code is both called-for and headache-inducing?
> >>
> >> ~Robert Widmann
> >>
> >> 2016/11/19 18:48、Alexander Doloz via swift-evolution <swift-evolution at swift.org> のメッセージ:
> >>
> >>> Hello, Swift community!
> >>>
> >>> Right now, when we declare nested types in Swift, we have to literally nest them:
> >>>
> >>> // Swift 3
> >>> struct A {
> >>>  var a = 0
> >>>  struct B {
> >>>      var b = 0
> >>>      struct C {
> >>>          var c = 0
> >>>          func someFunc() {
> >>>              if something {
> >>>
> >>>              }
> >>>          }
> >>>      }
> >>>  }
> >>> }
> >>>
> >>> By nesting types this way we waste amount of indents we can do without losing readability. In the example above, code inside if statement will already be far away from left border.
> >>> I propose to allow do nested types like this:
> >>>
> >>> // Proposal
> >>> struct A {
> >>>  var a = 0
> >>> }
> >>>
> >>> struct A.B {
> >>>  var b = 0
> >>> }
> >>>
> >>> struct A.B.C {
> >>>  var c = 0
> >>>  func someFunc() {
> >>>      if something {
> >>>
> >>>      }
> >>>  }
> >>> }
> >>>
> >>> No more unnecessary indentation.
> >>> Of course, the old way should also continue to work.
> >>>
> >>>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution