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
([email protected]) 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
<[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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
