Re: [swift-evolution] Add code to super methods.

> On 20 Nov 2016, at 16:00, Tino Heth <2...@gmx.de> wrote: > > >> I'm not sure I follow your meaning on omission; I quite like Sean's >> suggestion of having an override(before) or override(final) in the >> sub-class, this way the call is explicitly auto-generated. I think having it >> be

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

Oops, I could've sworn that I did change the subject! Thanks, Adrian. > On Nov 20, 2016, at 2:07 PM, Adrian Zubarev > wrote: > > Forwarding your message to the right thread. > > Please use this subject pattern when replying to something: > > Re: +

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 Zubarev Sent with

Re: [swift-evolution] SE proposal: Add @objc to enum strings

It seems like a sensible/reasonable approach, but personally I don't care about accessing Swift from Obj-C, or writing Swift that can be called from Obj-C. On Sun, 20 Nov 2016 at 18:15 Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > Does anyone have any thoughts on this

[swift-evolution] (no subject)

+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

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] SE proposal: Add @objc to enum strings

Does anyone have any thoughts on this idea? I Made a draft proposal of this very idea https://github.com/wh1pch81n/swift-evolution/blob/master/proposals/-Swift-enum-strings-ported-to-Objective-c On Sat, Nov 19, 2016 at 2:44 PM Derrick Ho wrote: > [TL;DR] > SE-0033

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] [Review] SE-0145: Package Manager Version Pinning (Revised)

> What is your evaluation of the proposal? It seems like a sensible step on the way to more advanced workflow, stats, testing, checking upgrades, and reporting features - without closing any doors. > If you have used other languages or libraries with a similar feature, how do you feel that this

Re: [swift-evolution] Global init() functions

Alan, The other thread subject is "Getting a list of protocol conformers" On Sun, 20 Nov 2016 at 14:40 Alan Cabrera via swift-evolution < swift-evolution@swift.org> wrote: > On Nov 19, 2016, at 8:57 PM, John McCall wrote: > > On Nov 19, 2016, at 6:03 PM, Alan Cabrera

Re: [swift-evolution] [Pitch] Setup Block

Hi Andrew, There is a similar discussion (in that it solves some aspects of the same problem) going on at the moment with the subject "Add code to super methods" - check it out. The parts of this problem it doesn't address is that you would still have to override multiple init methods to ensure

Re: [swift-evolution] Add code to super methods.

> I'm not sure I follow your meaning on omission; I quite like Sean's > suggestion of having an override(before) or override(final) in the sub-class, > this way the call is explicitly auto-generated. I think having it be added > automatically in the regular override case could be a bit

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] Global init() functions

> On Nov 19, 2016, at 8:57 PM, John McCall wrote: > >> On Nov 19, 2016, at 6:03 PM, Alan Cabrera > > wrote: >>> On Nov 19, 2016, at 4:02 PM, John McCall >> > wrote: >>>

Re: [swift-evolution] Add code to super methods.

> On 19 Nov 2016, at 17:08, Tino Heth <2...@gmx.de> wrote: > > I still thing that the naming is one of the hardest parts: > Imho "@super" just feels wrong — the word has already a meaning, and it > should only be used when referring to the parent class (here, it is a > restriction/hint for

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 Draft] Provide Custom Collections for Dictionary Keys and Values

@Nate: Just another pitch. Do we really want the DocumentValues to be a MutableCollection? There are default implementations like sort which would destroy the correctness of your unordered dictionary. IMO all mutating functionality should be added manually to DocumentValues to ensure that it

Re: [swift-evolution] [Pitch] Setup Block

Initialization is already quite complex in Swift, so I'm very wary of adding new features and prefer Derricks idea over a new language feature. I hope Swift is still flexible enough for deep changes in this area — I guess enforcing that there is always a single designated initializer would not

Re: [swift-evolution] [swift-users] Implementing signum

>From some older evolution-thread: extension SignedNumberType { var sign: Self { if self == (0 as Self) { return (0 as Self) } else if self > (0 as Self) { return (1 as Self) } return (-1 as Self) } } -- Adrian Zubarev Sent with Airmail Am 20. November 2016 um 03:44:04, Rick