Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Sent from my iPhone > On 12 Jan 2018, at 18:25, Jordan Rose via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>>

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I am sorry, but I have to disagree here. Having two separate proposals would make it highly more likely that one thing is done and the other one postponed and postponed until it seems no longer relevant in the grand scheme of things... first we lost labels in callbacks / stores functions (has

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Add -Weverything and you can ensure you are switching exhaustively ;). Sent from my iPhone > On 8 Jan 2018, at 19:02, Javier Soto via swift-evolution > wrote: > > This is very much an issue in Obj-C today. If you have an NS_ENUM defined > with cases A, B, and C,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

in this be? Sent from my iPhone > On 5 Jan 2018, at 09:11, Gwendal Roué <gwendal.r...@gmail.com> wrote: > > >> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> I feel like this change

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

edo Marocchi via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Furthermore, the old code needs to continue working without source

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution > wrote: > > Furthermore, the old code needs to continue working without source changes, > because updating to a new SDK must not break existing code. (It can introduce > new warnings, but even that is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Sent from my iPhone > On 3 Jan 2018, at 07:42, Goffredo Marocchi wrote: > > >> On 3 Jan 2018, at 02:07, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

This is not what I am saying. Change X helps use case A, but unnecessarily removes feature important (and like argument labels for everything quite Swift defining, but alas...) for use case B. What I am saying is that before merging change X we should figure out what is needed (change Y) to

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 3 Jan 2018, at 00:38, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Jan 2, 2018 at 4:31 PM, Jonathan Hull wrote: >> I think there are a couple of different definitions running around, and that >> is confusing things. >> >> In my mind,

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Hello all, > On 2 Jan 2018, at 18:36, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Jan 2, 2018 at 12:11 PM, Jason Merchant via swift-evolution >> wrote: >> I think this whole thing has been unnecessarily convoluted. As a result,

Re: [swift-evolution] Happy new year Swift community.

Happy new year everybody :)! Sent from my iPhone > On 31 Dec 2017, at 23:43, David Hart via swift-evolution > wrote: > > Thank you very much and happy new Swift year to everybody. > >> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution >>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

+1 kind of eye opening looking at it from that angle :/. Sent from my iPhone > On 21 Dec 2017, at 18:02, Dave DeLong via swift-evolution > wrote: > > I realized further why we should not implement this proposal: It forces the > problem of binary compatibility on

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

+1 thanks for your response Chris, it seems to me that it addresses the need this PR is trying to address and it does make it so in a scalable way. I would strongly hope your feedback is added to the proposal and shapes the final solution. Sent from my iPhone > On 21 Dec 2017, at 07:14, Chris

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for > non-exhaustive enums" : I see the completeness check as a major feature of > enums, that makes a difference between it and a list of constants in multiple > cases. > So much that in the coding rules of the

Re: [swift-evolution] Add transformers to Codable

+1 this is missing functionality at the moment and what still puts tools like Mantle ahead. Sent from my iPhone > On 19 Dec 2017, at 04:18, Charlie Monroe via swift-evolution > wrote: > > For me definitely +1 as it's getting near to what I need to call the Decoding

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Well, mocking was effective and super easy to do proper unit testing with... that must count as a disaster or something ;). Sent from my iPhone > On 7 Dec 2017, at 15:32, C. Keith Ray via swift-evolution > wrote: > > Let's see what disasters were created by people

Re: [swift-evolution] proposal 0143-conditional-conformances

In many software projects in the real world the tests would have been gone not the code... *weeps as that is so true :/“... Sent from my iPhone On 20 Nov 2017, at 08:16, Brent Royal-Gordon via swift-evolution wrote: >> On Nov 19, 2017, at 4:11 PM, Matt Whiteside

Re: [swift-evolution] proposal 0143-conditional-conformances

+1 Sent from my iPhone > On 20 Nov 2017, at 00:11, Matt Whiteside via swift-evolution > wrote: > > Just wanted to upvote the conditional conformances proposal. > > I was bummed to find out that I couldn’t do this: > > extension Array:Drawable where Element ==

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Very interesting indeed... class VehicleUtilities { int numberOfAxles(Vehicle v) { return 2;} // a plausible default int numberOfAxles (Truck t){ return 3;} } Vehicle v = new Truck(); VehicleUtilities u = new VehicleUtilities(); u.numberOfAxles(v); // returns 2 --> this is a nice

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPhone > On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution > wrote: > > Through great pain and community anguish, we pushed ourselves to a model > where argument labels are parts of the declaration name, not part of the call > argument Hey Joe,

Re: [swift-evolution] Abstract methods

I would say that you kind of already entered a slippery slope when the extension to a protocol can add code / not just declare a behavioural contract and how it changes OOP approach (hence: https://bugs.swift.org/plugins/servlet/mobile#issue/SR-302 and https://bugs.swift.org/browse/SR-103

Re: [swift-evolution] Abstract methods

Sent from my iPhone > On 4 Nov 2017, at 05:26, Slava Pestov via swift-evolution > wrote: > > Protocols define requirements, they don’t “add” things to the conforming type I agree with this, but then this warrants a change for protocol extensions too. Would you be

Re: [swift-evolution] Adding Result to the Standard Library

Key words: “if that is going to change” and I would add “even if it changes would all async use cases map to the new paradigm?”. I understand your concerns, but I am also wary of promised silver bullet solutions that promise or aim to take care of all use cases... Sent from my iPhone > On 2

Re: [swift-evolution] continuations - "extensions on steroids" idea

I like the IB use case :). Sent from my iPhone > On 31 Oct 2017, at 03:22, Adam Kemp via swift-evolution > wrote: > > This I actually support. In C# the same concept exists in the form of partial > classes. A class must be declared as partial everywhere in order to

Re: [swift-evolution] [SPM] Roadmap?

Very well said, I kind of think that at this point in time you do much more for the language by investing into SPM properly than Actors/Coroutines if you had to choose. Sent from my iPhone > On 28 Oct 2017, at 14:26, Karl Wagner via swift-evolution > wrote: > >

Re: [swift-evolution] Property Getter Return Statement

Will this finally bring labels back everywhere (closures and stored functions too)? :D. On Thu, Oct 12, 2017 at 3:03 PM, Jeremy Pereira via swift-evolution < swift-evolution@swift.org> wrote: > > > > > > I’m minorly opposed, because it feels like a slippery slope. What about > function bodies?

Re: [swift-evolution] Enums and Source Compatibility

Agreed, I am not seeing this change doing so much good because maybe it could prevent issues Library writers or developers updating libraries without checking things... not trying to be rude and/or non empathetic, but exhaustive enums never struck me as a bad thing and the reasons why they

Re: [swift-evolution] Enums and Source Compatibility

I am still unsure why we are choosing again a default that protects library writers more than library users where it is reasonable to expect the former to have better mastery of the language, to architect a library with some scalability, and ability to add unit test to cover themselves from

Re: [swift-evolution] Enums and Source Compatibility

Sorry for being naive, but aside from open (and the decision not to make it the default which again hurts the users of the library), wouldn’t the playground library example be ok if the framework author had validated it with unit tests? Sent from my iPhone > On 16 Sep 2017, at 01:07, Jordan

Re: [swift-evolution] Persistent Collections with full COW support

No sure if this is they will make stdlib, but ai am sure people would like to take a look at it :). Sent from my iPhone > On 1 Sep 2017, at 17:26, Sebastian Bohmann via swift-evolution > wrote: > > Is swift evolution interested in a set of persistent collections

Re: [swift-evolution] New async keyword usage

Sent from my iPhone > On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution > wrote: > > C# had futures (in the form of the Task Parallel Library) before it had > async/await. If you could see how much async/await has revolutionized C# > programming you would

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

With both he now built in promises in Node8 as well as libraries like Bluebird there was ample time to evaluate them and convert/auto convert at times libraries that loved callback pyramids of doom when the flow grows complex into promise based chains. Converting to Promises seems magical for

Re: [swift-evolution] [Concurrency] Async/Await

Just to get it out of the way and to put the issue down... assuming we could get something like Promises and Futures, how much experience do people have with how async and await + Promises are changing the asynchronous by nature JavaScript? What in there really does not work and should one of

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

Sorry, I thought that the default implementation in the protocol extension was how this was provided. > Providing Default Implementations > You can use protocol extensions to provide a default implementation to any > method or computed property requirement of that protocol >

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

We can override the protocol default implementation in the extension, but the issue I see with default implementation in Swift is that if I pass the object created this way around in a type erased container (Any : Protocol1 like it was common for many to pass id around in the Objective-C

Re: [swift-evolution] Swift 5: start your engines

Async / await is really spoiling me in Node.JS at the moment, you leave with shiver with anticipation!!! :) Sent from my iPhone > On 9 Aug 2017, at 06:41, Chris Lattner via swift-evolution > wrote: > > >> On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution

Re: [swift-evolution] Inconsistencies related to prepositions

>>> generally any of the wonderful languages that choose a different tradeoff >>> regarding convenience over expressiveness. Otherwise, I'm not really sure >>> what productive forward movement bringing up complaints about a fundamental >>> philosophical underpinnin

[swift-evolution] Fwd: Inconsistencies related to prepositions

a message earlier this > week, swift-evolution is a list to discuss making changes to the Swift > language, not a list for ranting about things in Swift you don't like but > cannot change. > > Regards, > Austin > > On Aug 2, 2017, at 11:43 PM, Goffredo Marocchi via swift-evo

Re: [swift-evolution] Inconsistencies related to prepositions

Sent from my iPhone > On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> Brent had a draft proposal to revise the names of collection

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Sent from my iPhone > On 3 Aug 2017, at 01:09, Jordan Rose via swift-evolution > wrote: > > > 'required' initializers are like methods: they may require dynamic dispatch. > That means that they get an entry in the class's dynamic dispatch table, > commonly known

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

Sent from my iPhone > On 31 Jul 2017, at 08:40, Xiaodi Wu via swift-evolution > wrote: > > >> On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution >> wrote: >> > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

> They are _not_ meant to reopen the floor for anyone who already voiced their > opinion on the original proposal simply to restate their opposition to > particular changes. Yes, Xiaodi I understand you are trying to help, but I find that sometimes you do talk down to other posters a bit

Re: [swift-evolution] Pitch: Improved Swift pointers

Mmh, I think like the do while -> repeat while change it makes sense, but not enough to displace the obvious meaning of the original... but then again, I lost back then... Sent from my iPhone Begin forwarded message: > From: Andrew Trick via swift-evolution > Date:

Re: [swift-evolution] ability to derive a class from a struct or other value type

Sent from my iPhone > On 23 Jun 2017, at 21:08, Haravikk via swift-evolution > wrote: > > >> On 23 Jun 2017, at 16:20, Mike Kluev wrote: >> >> on Fri Jun 23 05:26:11 CDT 2017 Haravikk swift-evolution at haravikk.me >> wrote: >> >> > Not

Re: [swift-evolution] Revisiting SE-0110

It seems to me that we have a general problem with labels and every time we have to push things around they break and we simply rip them out: first with argument labels in closures and stores functions (sigh... :/, but we may get labels back somehow there one day not too far from now hopefully)

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Sent from my iPhone > On 14 Jun 2017, at 21:41, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Jun 14, 2017 at 3:37 PM, Vladimir.S via swift-evolution >> wrote: >>> On 14.06.2017 21:23, Haravikk via swift-evolution wrote: >>>

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

If it is low cost and people do not come up with regressions/high cost + negative impact scenarios then I would say go full steam ahead. It does address an annoying scenario. Sent from my iPhone > On 10 Jun 2017, at 12:04, Gor Gyolchanyan wrote: > > Not much, I think.

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

Quite interesting :), what impact would it have on the compiler? Sent from my iPhone > On 10 Jun 2017, at 11:46, Gor Gyolchanyan via swift-evolution > wrote: > > I think a better way of achieving this would be to use the already existing > `where` keyword in loops.

Re: [swift-evolution] Ownership on protocol property requirements

Sent from my iPhone > On 8 May 2017, at 08:44, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> I can understand that, I am just wary of "le

Re: [swift-evolution] Ownership on protocol property requirements

ater. >>>>>> >>>>>> The source-breaking bug fix that is more pressing today is removing >>>>>> meaningless keywords that can be misleading to users, because they have >>>>>> no effect but look like they should. >>>> Exact

Re: [swift-evolution] Ownership on protocol property requirements

eywords that can be misleading to users, because they have no >>>> effect but look like they should. >> Exactly the trap I fell into when I found this issue. >> >>> >>> Yup, +1. Who wants to write a proposal? >> >> I'd like to give it a try. I c

Re: [swift-evolution] Ownership on protocol property requirements

It would be useful to have a longer discussion on this as... I think that weak has a place there and should be enforced as a protocol is the public facing interface/api for the types who decide to adopt it. Sent from my iPhone > On 7 May 2017, at 15:41, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

That is weird indeed, there is need of more argument labels, like argument labels back in stored closures and callbacks, not even less argument labels all around :/. -1 as a corner case of the language throws the baby out with the bathwater. Sent from my iPhone > On 5 May 2017, at 05:53,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

Sent from my iPhone > On 3 May 2017, at 02:05, Howard Lovatt via swift-evolution > wrote: > > My experience with languages that have generalised existential is that they > are superior in many circumstances; not just for collections, e.g. I gave the > example of

Re: [swift-evolution] [pitch] Comparison Reform

Sent from my iPhone > On 28 Apr 2017, at 01:51, Jonathan Hull via swift-evolution > wrote: > > To be clear, the big downside is the current lack of hardware support. There > are apparently some chips in the pipeline, but nothing for Apple platforms > that I know

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

der = JSONEncoder() > let payload = try encoder.encode(person) > print(String(data: payload, encoding: .utf8)!) // => {"name": "John Doe", > address: {"street": "1 Infinite Loop", ... } } > > let decoder = JSONDecoder() > let decode

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

Sent from my iPhone > On 26 Apr 2017, at 17:24, Tony Parker via swift-evolution > wrote: > > Hi Riley, > >> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution >> wrote: >> >> I’m sure this has already been discussed, but

Re: [swift-evolution] [pitch] Comparison Reform

Sent from my iPhone > On 23 Apr 2017, at 05:58, Chris Lattner via swift-evolution > wrote: > >> On Apr 22, 2017, at 6:06 PM, Xiaodi Wu wrote: >> but my quick reaction to `&==` is that it would make me quite nervous to >> have `==` not bound

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

Sent from my iPhone > On 20 Apr 2017, at 23:15, John McCall wrote: > > >> On Apr 20, 2017, at 5:50 PM, Goffredo Marocchi wrote: >> >> One thing I wanted to point out and that was a non trivial issue last year >> and that the core team did discuss and

Re: [swift-evolution] [Accepted] SE-0155: Normalize Enum Case Representation

One thing I wanted to point out and that was a non trivial issue last year and that the core team did discuss and agreed to revisit (if I remember the thread update by Chris Lattner last year): > Note that since the labels aren't part of a tuple, they no longer participate > in type checking,

[swift-evolution] Fwd: [Review] SE-0172: One-sided Ranges

Sent from my iPhone Begin forwarded message: > From: Goffredo Marocchi > Date: 18 April 2017 at 07:33:54 BST > To: Douglas Gregor > Subject: Re: [swift-evolution] [Review] SE-0172: One-sided Ranges > > +1 seems like a slam dunk of a proposal. Far

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

+1 Sent from my iPhone > On 13 Apr 2017, at 08:15, Tino Heth via swift-evolution > wrote: > >> No change >> Benefit: No change to the language. >> Drawback: Must use “fileprivate” to build up a type through extensions. >> >> SE–0159 >> Benefit: Simplifies the

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Sent from my iPhone > On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution > wrote: > > I'm honestly having trouble believing that this is being seriously > proposed... I always saw type inference as one of the most important > advantages of Swift over some

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

We currently pay a dear cost in compilation time for all the features Swift brings and this in itself harm productivity quite a bit, the gulf between Swift and Objective-C projects compile time wise is massive and right nowt seems like we are ignoring it sometimes. Type inference can be a non

Re: [swift-evolution] SE-0169

Sent from my iPhone > On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution > wrote: > > All - > > I am not in favor of this change. While I agree that the implementation of > fileprivate and open as well as the changes to private had some unintended >

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Type inference sounds nice initially then you face the costs in compilation time and reduced ability to debug and reason about the code months after the fact... and you start to rethink things (not every programmer keeps maintainability over pretty smart haiku code). Sent from my iPhone > On

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Sent from my iPhone > On 7 Apr 2017, at 09:56, Jonathan Hull via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > Strong -1. Just rename ‘fileprivate’ to be less annoying. So, we keep being told it won't happen and our current Bly

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

We should evaluate the proposal in terms of what it can do not in "we are upset we are not getting that old proposal reverted" or "I want something else which I know I am not going to get". Sorry if this is a bit direct, meant no offence. Sent from my iPhone > On 7 Apr 2017, at 01:05,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Sent from my iPhone > On 7 Apr 2017, at 00:25, Slava Pestov via swift-evolution > wrote: > > Strong -1. This is a source breaking change, but Swift 4 stage 2 is already > over. Considering the importance of access control for a lot of people and the rare chance

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

+1 this is perhaps the best compromise between the two views on access control I have seen in a while and the change is actually very tiny yet meaningful. Thanks David and Chris! Sent from my iPhone > On 7 Apr 2017, at 00:10, Douglas Gregor via swift-evolution >

Re: [swift-evolution] Type-based ‘private’ access within a file

Sent from my iPhone > On 4 Apr 2017, at 03:20, Shawn Erickson via swift-evolution > wrote: > > Yeah I think the best course of action is to leave things alone until such > time as we can more holistically work things as you outline. Considering how small this

Re: [swift-evolution] Type-based ‘private’ access within a file

Sent from my iPhone > On 4 Apr 2017, at 02:16, Jonathan Hull via swift-evolution > wrote: > > This is very disappointing. We can’t realistically get access controls > correct until we have a story around submodules, etc. Those things are out > of scope for Swift

Re: [swift-evolution] Type-based ‘private’ access within a file

Sent from my iPhone > On 4 Apr 2017, at 01:01, David Waite via swift-evolution > wrote: > > Soft -1 for four reasons: > > 1. I would expect private to be used to hide implementation details and type > invariants from all code, to encapsulate and protect the unsafe

Re: [swift-evolution] Type-based ‘private’ access within a file

+1 Sent from my iPhone > On 3 Apr 2017, at 22:21, David Hart via swift-evolution > wrote: > > >>> On 3 Apr 2017, at 23:19, John McCall wrote: >>> >>> On Apr 3, 2017, at 5:11 PM, David Hart via swift-evolution

[swift-evolution] Fwd: Type-based ‘private’ access within a file

Sent from my iPhone Begin forwarded message: > From: Goffredo Marocchi > Date: 3 April 2017 at 22:39:25 BST > To: Douglas Gregor > Subject: Re: [swift-evolution] Type-based ‘private’ access within a file > > +1 this brings some of the best points

Re: [swift-evolution] Type-based ‘private’ access within a file

Sent from my iPhone > On 3 Apr 2017, at 22:03, Matthew Johnson via swift-evolution > wrote: > > >>> On Apr 3, 2017, at 3:54 PM, Douglas Gregor wrote: >>> >>> On Apr 3, 2017, at 1:13 PM, Matthew Johnson wrote:

Re: [swift-evolution] [Proposal] Factory Initializers

Sent from my iPhone > On 1 Apr 2017, at 00:35, Riley Testut via swift-evolution > wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker wrote: >> >> This needs more explanation. It is allowed for a subclass to implement a >> convenience

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 26 Mar 2017, at 06:54, John McCall via swift-evolution > wrote: > >> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution >> wrote: >> Yes, it would change my opinion of it. I wouldn't become a strong

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 24 Mar 2017, at 05:36, Xiaodi Wu via swift-evolution > wrote: > > I agree with everything you wrote here. And it is for that reason that I > would expect that any future proposal for submodules should be judged in no > small part on its

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution >> wrote: >> >> One point which was raised by a couple of different

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 22:49, Charles Srstka via swift-evolution > wrote: > >> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution >> wrote: >> >> That’s why protected (a feature) is on the commonly rejected

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 18:41, David Hart via swift-evolution > wrote: > > > > > > Sent from my iPhone > On 21 Mar 2017, at 16:57, Drew Crawford wrote: > >> >> >>> > I’m not arguing that it is less or more than a

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 15:57, Drew Crawford via swift-evolution > wrote: > > > >> > I’m not arguing that it is less or more than a majority. I’m just saying >> > that we’ve seen a lot of talk against the original change. > > This proposal asks

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 20:36, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 21 Mar 2017, at 16:23, Davor Jankolija via swift-evolution >> wrote: >> >> >>> What is your evaluation of the proposal? >> >> + 1.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Forgot to cc. Sent from my iPhone > On 21 Mar 2017, at 07:43, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 21 Mar 2017, at 02:33, Greg Parker via swift-evolution >> wrote: >> >> >>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 07:05, Rien via swift-evolution > wrote: > > +1 > >>• What is your evaluation of the proposal? > > Makes the language easier to understand, lowers cognitive load during coding. Is it really a problem for cognitive load

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On 21 Mar 2017, at 05:48, Charles Srstka via swift-evolution > wrote: > >> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> Charles Srstka's added comment, while intriguing, poses a

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPhone > On 16 Mar 2017, at 01:18, Joe Groff via swift-evolution > wrote: > > Congrats on getting this out! A question from the field: > > https://twitter.com/mdiep/status/842178457115230210 Why does the Swift > Serialization API proposal use

Re: [swift-evolution] [Discussion] Simplifying case syntax

I would think that removing confusion and simplifying + rationalising the syntax IS the definition of a breaking change justified :). I do not see how Erica's proposal is in any way contrary to the philosophy behind the language or is removing anything people really depend on now (in terms of

Re: [swift-evolution] final + lazy + fileprivate modifiers

Hey Slava, > On 22 Feb 2017, at 23:07, Slava Pestov via swift-evolution > wrote: > > >> On Feb 21, 2017, at 4:19 PM, David Waite via swift-evolution >> wrote: >> >> >>> On Feb 21, 2017, at 2:27 AM, Joanna Carter

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

Well said, thanks for taking time to post this :). Sent from my iPhone > On 22 Feb 2017, at 19:34, Tino Heth via swift-evolution > wrote: > > >> This is bad faith. The original discussion contains many real life example. > "bad faith"? Really? If we have the same

Re: [swift-evolution] Argument labels in callbacks

s:error:): (Bool, Error?) -> Void = ... > callback(success: true, error: nil) > > This way the type itself wouldn't contain the label information, but the name > of the variable would. > >> On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution >> <swift-evolut

Re: [swift-evolution] Argument labels in callbacks

I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

Maybe some people disagree with the emphasis on the library writer POV and from a user perspective of other people's libraries they have been accustomed to how you can be trusted with enough responsibility to either fix a behaviour in the binary lib you have been given or modify the sequence of

Re: [swift-evolution] [Proposal Draft] Remove open Access Modifier

To those people I would say use final or let's change public to mean the current open and replace open with 'module'... I liked open by default and this not needing open in the first place... you guys got me here ;). Sent from my iPhone > On 21 Feb 2017, at 07:02, David Hart via

Re: [swift-evolution] final + lazy + fileprivate modifiers

Ok, on this I can agree... and I will. It try to mention how judging things by how "Swifty" they are makes us seem like a cult... but then again we are programmers/engineers... that word may very well apply appropriately :). Sent from my iPhone > On 20 Feb 2017, at 08:46, Jonathan Hull

Re: [swift-evolution] final + lazy + fileprivate modifiers

Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/. Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth

Re: [swift-evolution] final + lazy + fileprivate modifiers

Maybe the burden of proof required for this change is not met even though it frustrates those who dislike fileprivate. I honestly think our energies are better spent on other parts of the language than arguing on this... unless the discussion has time to grow into a proper holistic manifesto on

Re: [swift-evolution] final + lazy + fileprivate modifiers

of people: people that are used to scoped-access from other > languages and people who prefer an access level which works better with > Swift’s idioms. It’s wasteful to keep two around IMHO. > >> Sent from my iPhone >> >>> On 19 Feb 2017, at 13:55, David Hart <

Re: [swift-evolution] final + lazy + fileprivate modifiers

<da...@hartbit.com> wrote: > > > >> On 19 Feb 2017, at 10:20, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The current private is closer to other languages than the previous one we >> had which now has in

  1   2   3   >