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

[Adrian Zubarev]

I always wanted something like this. Can't we extend the idea a little further and make it `flat extension` instead?  

struct A {}  

func A.foo() {}  

struct A.B {}  

It would be some sugar for `extension A { ... }`

--  
Adrian Zubarev
Sent with Airmail  

Am 20. November 2016 um 04:18:32, Robert Widmann via swift-evolution (swift-evolution at swift.org(mailto:swift-evolution at swift.org)) schrieb:

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