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