+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!
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@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.
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@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@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.
Hahaha, that’s exactly what I was thinking when I originally subscribed to the mailing list several months ago, but eventually I came to the conclusion that “well, these are a lot of really smart people, maybe there is a super compelling reason that they’re using a mailing list rather than oh, I don’t know, ANY modern message board platform.”