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 <[email protected]> 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
> <[email protected]> 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 <[email protected]> написал(а):
> >
> > 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
> >> <[email protected]> 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
> >> <[email protected]> のメッセージ:
> >>
> >>> 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
> >>> [email protected]
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> _______________________________________________
> >> swift-evolution mailing list
> >> [email protected]
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
