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

> On 21 Nov 2016, at 11:52, Jeremy Pereira > wrote: > > >> On 21 Nov 2016, at 08:42, Rien via swift-evolution >> wrote: >> >> Sure you can do that, but I rather write: >> >> struct A.B {…} >> >> than >> >> extension A { struct

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

> On 21 Nov 2016, at 08:42, Rien via swift-evolution > wrote: > > Sure you can do that, but I rather write: > > struct A.B {…} > > than > > extension A { struct B {…} } > > The first seems much “swiftier” to me. Hmm, objectively, it’s not “swiftier” is it,

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

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

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

> On Nov 20, 2016, at 3:22 PM, Tino Heth <2...@gmx.de> wrote: > >> Oops, I could've sworn that I did change the subject! > Feel free to join camp "isn't there something better than mailing lists?" ;-) Hahaha, that’s exactly what I was thinking when I originally subscribed to the mailing list

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

The forum can’t appear soon enough. :D --  Adrian Zubarev Sent with Airmail Am 20. November 2016 um 22:23:03, Tino Heth via swift-evolution (swift-evolution@swift.org) schrieb: Oops, I could've sworn that I did change the subject! Feel free to join camp "isn't there something better than

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

> Oops, I could've sworn that I did change the subject! Feel free to join camp "isn't there something better than mailing lists?" ;-) ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

thing: > > Re: + [swift-listname] + Topic name > > As for the current thread: > > Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types > > Best regards, > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 20. Novem

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

Forwarding your message to the right thread. Please use this subject pattern when replying to something: Re: + [swift-listname] + Topic name As for the current thread: Re: [swift-evolution] Proposal: Allow "flat" declaration of nested types Best regards, --  Adrian Zu

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

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

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

No problem Alexander! On Sun, Nov 20, 2016 at 1:15 PM Alexander Doloz wrote: > Frankly speaking I didn’t know it’s possible with extensions :) Thank you > for answer, it will be helpful for my project. > Since this method works my proposal no longer makes much sense. > >

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

Frankly speaking I didn’t know it’s possible with extensions :) Thank you for answer, it will be helpful for my project. Since this method works my proposal no longer makes much sense. > 20 нояб. 2016 г., в 21:05, Derrick Ho написал(а): > > struct A { >var a = 0 > } >

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

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") }

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

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

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

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

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

I always wanted something like this. Can't we extend the idea a little further and make it `flat extension` instead? struct A {} func A.foo() {} struct A.B {} It would be some sugar for `extension A { ... }` -- Adrian Zubarev Sent with Airmail Am 20. November 2016 um 04:18:32,