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

[Rien]

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