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

[Derrick Ho]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161120/79ee9383/attachment.html>