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

[Adrian Zubarev]

Real type nesting vs. extension nesting creates a new visibility boundary. If your type somehow depends on the visibility of your parent type scope, it could became problematic. Just speaking generally here.

Bikeshedding:

struct A {
    struct B {}
}

extension A {
    struct C {}
}

// Could be written as

@scoped
struct A.B {}

@extension // where this could be by default and fully inferred
struct A.C {}  


-- 
Adrian Zubarev
Sent with Airmail

Am 20. November 2016 um 19:06:13, Derrick Ho via swift-evolution (swift-evolution at swift.org) schrieb:

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
_______________________________________________
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/1c73f7c4/attachment.html>