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

out protocol initializers. This > would bring together some of the best aspects of both Objective-C class > clusters and Swift protocol-oriented programming and would be a huge benefit > to application developers. > > Charles > >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swif

Re: [swift-evolution] [Proposal] Protected Access Level

Unless I'm missing something Brent, your suggestions still wouldn't allow the developer to provide a public class in a module designed to be subclassed by clients in another module and access these "private" details, which is a real problem I'm having in my current project. I have a framework

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

, 2016, at 11:26 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Recently, I proposed the idea of adding the ability to implement the "cla

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

y init(type: InformationToSwitchOn){ > if let subclass = factory.init(type){ > return subclass > } > return self.init()//If subclasses didn’t work, initialize ourselves > } > } > > Thoughts? Too crazy to consider? > > Thanks, > Jo

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

ets a shot >>>>> //Init concrete type here >>>>> } >>>>> } >>>>> >>>>> The main issue which still needs to be solved is that the order they get >>>>> called sometimes really matters (this was solved by a

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

t;>>>>> The idea here is to give each interested subclass a chance to say “I've >>>>>>> got this!”. The factory init runs through each of the subclasses’ >>>>>>> overrides until it finds one that doesn’t return nil. New subclasses >

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

be placed more >>> extremely early/late. Exact order is undefined, but rough ordering is >>> possible. >>> - return (to the superclass) an array of all subclasses which successfully >>> inited. It can then select which one it wants and return it. This seems

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

Cocoa Collections) >>>>>>>>>>> 2) I always feel a bit dirty giving the base class knowledge of >>>>>>>>>>> it’s subclasses >>>>>>>>>>> 3) It is a royal pain, and a potential source of

Re: [swift-evolution] Mutability for Foundation types in Swift

Very happy to see this proposal; felt strange that for a language so focused on value-types an entire framework open sourced with the language was composed entirely of reference-types (albeit for obvious reasons). So +1 for that. One particular section that caught my interest was this: > The

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

100% in favor of this proposal. IMO, Foundation should feel as natural to use as the Swift standard library; providing native Swift value types to represent many Foundation objects certainly brings us much closer to accomplishing that goal. My only concern is that the Swift wrappers should

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

FWIW, I'm still against this proposal, but since it will be accepted regardless, here are my thoughts: • Open keyword is significantly better. • Members should be *open* by default, and final should be opt-in. If you're opening up a class for subclassing, my gut says you should allow the

[swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements

Hello all, If you’ve been (attempting) protocol-oriented development in your own projects, I’m sure you’ve come across a particular build error at one point: > Protocol ‘MyProtocol' can only be used as a generic constraint because it has > Self or associated type requirements To be frank,

Re: [swift-evolution] [Proposal draft] NSError bridging

Love the proposal overall, but not sure about the CustomNSError name either. It doesn’t seem to read like a Swift protocol name. Somewhat related, is there a reason these protocols don’t contain the “Protocol” suffix? Stands in stark contrast with the rest of the Swift protocol naming

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

I kinda agree that these names still aren't the best. FWIW, I much preferred the originals, even if they could be misleading. What if we changed the names to be verbs instead of adjectives? Something like "IntegerLiteralTransforming"? > On Jul 2, 2016, at 10:35 AM, Dave Abrahams via

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

(My bad, accidentally hit send too early). That, or we could keep either the Convert or Express forms with "IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we decide "express" really is the best word to describe what happens, I personally prefer "IntegerLiteralExpressing" to

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

> When naming, we need to learn to stop treating the comfortable ring of > familiar word patterns as an arbiter of success. I’m not sure I agree with this statement. I would argue we should most certainly aim to keep a consistent feel across our naming conventions, and furthermore, I think

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

Wasn't there a proposal to stop defining methods in addition to global operators? I would very much support that, doesn't make sense to me to have two ways to do the same thing IMO. > On Jul 3, 2016, at 3:40 PM, Chris Lattner via swift-evolution > wrote: > > >> On

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

internally in such a way that >> they can return a value (as Objective-C init methods do), it may affect ABI >> stability and thus may be germane to the current stage of Swift 4 >> development. >> >> Charles >> >>> On Dec 17, 2015, at 3:41 PM, Riley Tes

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

uld it be implied by > "required" and using self-assignment in the init body? > > Best, > Zachary Waldowski > z...@waldowski.me > > >> On Fri, Mar 17, 2017, at 12:26 PM, Riley Testut via swift-evolution wrote: >> >> >> H

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

> 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 initializer that has the same signature as a superclass > convenience initializer or a superclass designated initializer. The >

Re: [swift-evolution] [Pitch] Adding safety to arrays

lt;saa...@saagarjha.com> wrote: > > A Dictionary uses a lot more space than an Array, though, and allow for bogus > keys like “-1”, etc. > > Saagar Jha > >>> On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution >>> <swift-evolution@swift.org> wrote: >&

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

> Using extensions for "code organization" is another word for writing > spaghetti code. Using extensions for code organization is a practice established and recommended by the Core Team from the very beginning (such as this blog post from August 2014:

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

+1 to the proposal, *especially* the addition of the RangeExpression protocol. That being said, I agree with the critiques over the chosen name. I also can't remember where exactly, but I do remember at some point hearing that the -Protocol suffix should be added to protocol names if needed to

Re: [swift-evolution] [Pitch] Adding safety to arrays

> Personally, the only valid use-case I can think of is when you want to > initialise an Array’s elements out-of-order - i.e., you want to set a value > for myArray[2] despite myArray[0] and [1] not being populated. In that case, > it would be better to have some kind of SparseArray type, and

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

> You’re right, I overgeneralized. Let me correct myself: > > From what I’ve seen so far [*], using extensions for "code organization" > often results in spaghetti code. > > [*] Observed as a contractor; iOS platform; average Joe's code. Fair :-) Another use case for extensions I had

Re: [swift-evolution] [Pitch] Adding safety to arrays

ements out-of-order  I don't think >> we'd need to add another type to the standard library for this use case. >> >> On Apr 16, 2017, at 11:22 AM, Saagar Jha <saa...@saagarjha.com >> <mailto:saa...@saagarjha.com>> wrote: >> >>> A Dictionary us

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

My 2c on access control regarding extensions + global variables: Another annoyance from SE-0025 was that "private" and "fileprivate" modifiers meant the same thing when dealing with extensions and global variables. Obviously this was for good reasons, but still seemed weird. Regarding

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

> The Core Team has rejected making such a major change in the interpretation > of 'private'. 'private' will be tied to scopes, now and forever. The only > question is whether extensions of the same type within a file should be > considered part of the same scope for the purposes of

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

<xiaodi...@gmail.com> wrote: >> >>> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> I cannot express how strongly I believe this is the direction Swift should >>> go, so a h

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

instead declare the extensions in another file. > On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution >> <swift-evolution@swift.org> wrote: >> I cannot express how strongly I believ

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

> Presumably, proponents of SE-0025. That is, after all, an explicit part of > that design, reviewed and approved by the Swift community and core team. I'd be curious how many people actually are doing this though. My understanding is this practice is not that common overall. Ultimately

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

I cannot express how strongly I believe this is the direction Swift should go, so a huge, gigantic, +1 from me. After thinking it over, I do not have any qualms with fileprivate itself. I think that the functionality provided by fileprivate is valuable, and I also agree it shouldn’t be the

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

Extremely happy to see this outcome. Thank you Core Team for dealing with the seemingly never-ending arguments about access control, hopefully the majority of that is behind us now :^) > On Apr 17, 2017, at 5:25 PM, Douglas Gregor via swift-evolution > wrote: > >

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

> I think its important to point out that its more than aesthetics: because the > simple file and extensions scenario are so common, it forces us to use both > private and fileprivate fairly regularly, which increases the total number of > access control to work with on a daily basis. And I

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

I’m sure this has already been discussed, but why are the methods throwing NSErrors and not Enums? If I’m remembering correctly, the original reason for this was because this was meant to be a part of Foundation. Now that this is in the Standard Library, however, it seems strange that we’re

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

t.org/pipermail/swift-evolution/Week-of-Mon-20170417/036001.html> > > Regards, > Anders Ah thanks, glad to hear this! > On Apr 25, 2017, at 6:30 PM, Anders Ha <he...@andersio.co> wrote: > >> >> On 26 Apr 2017, at 9:11 AM, Riley Testut via swift-evolution >&g

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Hi Gor  I’m very much in fan of a unified initialization syntax. I submitted my own proposal for factory initializers a while back, but since it wasn’t a focus of Swift 3 or 4 I haven’t followed up on it recently. In the time since last working on it, I came to my own conclusion that rather

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

>>>>>>>>> Am 11. Juni 2017 um 10:12:38, Gor Gyolchanyan (g...@gyolchanyan.com) >>>>>>>>> schrieb: >>>>>>>>> >>>>>>>>>> I always wondered, why is `indirect` allowed on the `enum` itself? >>>>>>>>>> Wouldn't it

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

;>>>>>>>> „To enable indirection for all the cases of an enumeration, mark >>>>>>>>>>> the entire enumeration with the indirect modifier—this is >>>>>>>>>>> convenient when the enumeration contains many cases th

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

Awesome! Updated my proposal to include what I believed to be the relevant portions of your indirect initializer idea. Let me know if there’s anything I missed or should change :-) https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md > On Jun 10,

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

IIRC I had a discussion with Douglas Gregor about the overriding aspect of factory initializers, and the takeaway was that it would just be like convenience initializers. Technically, convenience initializers cannot be overridden, but a subclass *can* implement a convenience method with the

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

>>>>>>> with the indirect modifier.“ >>>>>>> >>>>>>> If you really wish to reuse that keyword here we might need to remove >>>>>>> such shortcuts from the language (indirect enum, access modifier on >>>>>>> extensions, anything else?). >

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Just as one small data point, I had no idea private extensions still applied fileprivate access to all members (I thought that had changed when SE-0169 was implemented). I’ve been using private extensions extensively because I thought they *did* apply private access to everything, not

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 8, 2017, at 11:51 AM, Joe Groff wrote: > > In principle it makes sense, but there are implementation challenges we > didn't have time to consider. It would be nice to make this happen when we > have the time to make it work. Just out of curiosity, what were some of

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 9, 2017, at 9:01 AM, Philippe Hausler wrote: > > I have personally filed a few bugs on this; and I definitely consider it a > bug that we cannot store Any in generics for objc. There are however some > problem areas that might be worth considering while fixing

[swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

Hi Swift-Evolution, Back when SE-0057 (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md) was proposed, it included the following passage: The generic type parameters in Swift will always be class-bound, i.e., the generic class will have the

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

I’m overall +1, but I’m curious: would you be able to conform an enum from another module to ValueEnumerable via an extension, and still have the compiler generate the protocol requirements for you? I can imagine that the client of a framework with an enum may have a valid use for iterating

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution > wrote: > What is the use-case for a type conforming to this protocol but returning > nil? If there is a use case for that, why not have such an implementation > return “self” instead? I assumed it

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

-1. I agree this is a problem, but I think this is the wrong solution. I think the solution should be on the client side, not on the framework author’s side. I would be fine if enums from imported modules are non-exhaustive, as long as I can choose to treat them as exhaustive if I want to. And

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

Actually, from the other email thread about this same topic (thank god forums are almost here), I see the proposed syntax “final switch” for what I referred to as “switch!”, which I prefer. > On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution > <swift-evolution@swift.o