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

[Zach Wolfe]

Oops, I could've sworn that I did change the subject! Thanks, Adrian.

> On Nov 20, 2016, at 2:07 PM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
> 
> 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 Zubarev
> Sent with Airmail
> 
> Am 20. November 2016 um 20:25:50, Zach Wolfe via swift-evolution (swift-evolution at swift.org) schrieb:
> 
>> +14689 on this one. I'm working on a project right now where I have a significant amount of subtypes inside one of my types (gameboy emulator, creating abstractions on the io registers to make them more pleasant to deal with) and I have the subtypes split up into a bunch of files. With current syntax, all of these files are forced to adhere to the following pattern:
>> extension IORegisters {
>> struct X { body }
>> }
>> 
>> With this proposal, all of these files could be unindented to the left like so (and would arguably be more clear):
>> struct IORegister.X { body }
>> 
>> I'm in favour of allowing methods and computed properties to be declared in this way as well:
>> func A.doSomething() {}
>> var A.computedProperty: B {}
>> 
>> I also agree with the notion that this proposal should be viewed as syntactic sugar - a short-form way of writing extensions, nothing more - and as such should not have any weird semantic differences from them.
>> 
>> Also, this is my first reply on this list, hi everyone!
>> _______________________________________________
>> 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/9c900d53/attachment.html>