(no subject)


(Zach Wolfe) #1

+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!


(Adrian Zubarev) #2

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.

Also, this is my first reply on this list, hi everyone!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Zach Wolfe) #3

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.

Also, this is my first reply on this list, hi everyone!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #4

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

Feel free to join camp "isn't there something better than mailing lists?" :wink:


(Zach Wolfe) #5

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.”

This comes to mind: http://youtu.be/y-PvBo75PDo

···

On Nov 20, 2016, at 3:22 PM, Tino Heth <2th@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?" :wink:


(Adrian Zubarev) #6

The forum can’t appear soon enough. :smiley:

···

--
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 mailing lists?" :wink:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution