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

-1 as this is just another keyword change and removing the keyword does not bring more benefit to Swift as the fileprivate keyword gives currently. Fileprivate makes sense because creating extensions on objects in the same file is a heavily used feature in Swift. It is very common for implementing

Re: [swift-evolution] Disallowing unreachable code

This is more of a developer practice that a team implements than an actual Swift/Xcode language feature. Also, I believe (not 100% sure) this wouldn't work for functions/properties that are dynamically dispatched. The compiler wouldn't know if the function will be called until runtime. On Mon, Mar

Re: [swift-evolution] [Pitch] String revision proposal #1

Restoring Collection conformance back to String is a big win for Swift! This revision looks great but I agree with the naming I believe it should be SubString not Substring. I think SubString looks odd written out over Substring but it keeps the convention of SubSequence. On Wed, Mar 29, 2017 at 7

Re: [swift-evolution] [Pitch] String revision proposal #1

> > ...my vote would be to lowercase Subsequence. We can typealias > SubSequence = Subsequence to aid migration +1 didn't think that was an option. A good solution would be to have them either camel case (SubString, SubSequence) or just capitalized (Substring, Substring) either would be nice as l

Re: [swift-evolution] [Pitch] Collection Type Element Property Observers

I believe this will this impact performance on collections if you have to do a computation on every item. Also what about appending another collection to an existing collection? Will there be a willAdd(newValue: Collection)? Or will the willAdd(element: Element) be called multiple times? I think

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

Nice addition! What do you think of equal parameter named to are? nums.all(equal: 9) nums.all(are: 9) I think it reads better and adds an explicit action of what is being checked. > if nums.all(are: 9) { print("all elements are 9") } On Fri, Mar 31, 2017 at 9:28 AM, Ben Cohen via swift-e

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Quesition about this proposal. Will it be possibly to create an array of keyPaths and set an objects value with enumeration. Example: struct Foo { var firstName: String var lastName: String } let keyPaths = [#keyPath(.firstName), #keyPath(.lastName)] for key in keyPaths { foo[keyPath

[swift-evolution] [Pitch] Enum with generic cases

Here is my pitch on adding generics to enum cases and not to the enum type itself. Let me know if you have an improvements or modifications lets open it to discussion thank you swiftys! :)Enum with generic cases - Proposal: SE-

Re: [swift-evolution] [Pitch] Enum with generic cases

ipedia.org/wiki/Generalized_algebraic_data_type> > (GADTs), > which is the more programming-language-theoretical name for what you’re > describing here. > > - Doug > > > That said, I would love to be incorrect. > > On Mon, Apr 24, 2017 at 9:57 AM, Joshua Alvarado via

Re: [swift-evolution] [Pitch] Enum with generic cases

thing { > case thingOne(let s): > // What is the type of s? > case thingTwo(let i): > // is it even possible to write an exhaustive switch? > } > } > > > > On Apr 24, 2017, at 6:57 AM, Joshua Alvarado via swift-evolution < > swift-evolut

Re: [swift-evolution] [Pitch] Enum with generic cases

017, at 1:34 PM, Joshua Alvarado via swift-evolution >> wrote: >> >> Well in your case thing one and thing two will be the same type as you are >> using the same T generic type on both. >> >> To achieve your case you can do an extension on the enum an

Re: [swift-evolution] [Pitch] Enum with generic cases

thingOne(T) >>> case thingTwo(U) >>> } >>> >>> // How do I require thingOne or thingTwo? >>> func handle(thing: Thing) { >>> switch thing { >>> case .thingOne(let s): print("string \(s)") >>> case .t

Re: [swift-evolution] [Pitch] Enum with generic cases

do >> wrote: >> >> Hmmm interesting point it would be good to consider this and get to an >> implementation that helps cover both or just implement the desired feature >> and in the future add more resiliency. >> >> Alvarado, Joshua >> &g

Re: [swift-evolution] [Pitch] Enum with generic cases

ft 4, certainly. It may not look like it, but this is a >>> fairly large feature. I suggest reading up on generalized algebraic data >>> types (GADTs), which is the more programming-language-theoretical name for >>> what you’re describing here. >>> >>> -

[swift-evolution] Draft: Regular Expression in Swift

Hey everyone, I would like to pitch an implementation of Regex in Swift and gather all of your thoughts. Motivation: In the String Manifesto for Swift 4, addressing regular expressions was not in scope. Swift 5 would be a more fitting version to address the implementation of Regex in Swift. NS

[swift-evolution] [Draft] Swift implementation Regex added

My first proposal so take it easy on me :) This is a draft so feedback is very welcome and any help. Thank you swiftys. *Introduction* Swift doesn’t have a native implementation of Regex which is included in many other languages. This proposal is a suggestion to introduce a native Regex type i

Re: [swift-evolution] [Draft] Swift implementation Regex added

later release as the window for Swift 3 is >> closing >> >> Brandon >> >>> On Jul 25, 2016, at 12:24 PM, Joshua Alvarado via swift-evolution >>> wrote: >>> >>> My first proposal so take it easy on me :) This is a draft so feedback is

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

-1 I love the idea of challenging the syntax but without any real benefit I can see it harder for new devs and it will cause breaking changes that doesn't outweigh the cause. The syntax z ? x : y is not hard to comprehend and expresses powerful statements in just a simple line. I do agree it i

Re: [swift-evolution] guard let x = x

In your example the keyword only makes sense if you are shadowing the optional variable. How would unwrap work with a different name? Ex: guard let bar = foo else {...} guard unwrap bar else {...} -> There is no context to what the guard is unwrapping This could end up leading to: guard unwrap bar

Re: [swift-evolution] guard let x = x

Without going back through the history, is the proposal to keep replace guard or still keep guard keyword and create a new unwrap? If unwrap is added the guard keyword should just be removed. Alvarado, Joshua > On Oct 31, 2016, at 12:49 PM, Xiaodi Wu via swift-evolution > wrote: > > Because

Re: [swift-evolution] Strings in Swift 4

The strings proposal is a warm welcome to the Swift Language and I believe many developers are happy to see Strings become a priority. String processing may be one of the most common tasks for a developer day to day. That being said one thing in the proposal I believe is not correct is the leaving

[swift-evolution] [Discussion] mailing list alternative

Hey swifters, I would like to (re)open up discussion on moving away from email for the swift evolution mailing list. I know this has probably been discussed before but it really should be addressed again. I wouldn't even know how to find if it has been discussed before because it would be too har

Re: [swift-evolution] [Discussion] mailing list alternative

or Discourse. Cannot wait any longer for this to happen. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 23. Januar 2017 um 17:18:42, Joshua Alvarado via swift-evolution > (swift-evolution@swift.org) schrieb: > >> Hey swifters, >> I would like t

Re: [swift-evolution] [Discussion] mailing list alternative

t;> >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 23. Januar 2017 um 17:18:42, Joshua Alvarado via swift-evolution >> (swift-evolution@swift.org) schrieb: >> >>> Hey swifters, >>> I would li

Re: [swift-evolution] [Discussion] mailing list alternative

nice to mark discussions as related, duplicates, etc >> >> -DW >> >> On Jan 23, 2017, at 9:22 AM, Adrian Zubarev via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> +1 for Discourse <http://www.discourse.org/>. Cannot wait any lon

Re: [swift-evolution] [Discussion] mailing list alternative

epeat and diverging topics, and it would be >>> nice to mark discussions as related, duplicates, etc >>> >>> -DW >>> >>>> On Jan 23, 2017, at 9:22 AM, Adrian Zubarev via swift-evolution >>>> wrote: >>>> >>>> +1 f

Re: [swift-evolution] [Discussion] mailing list alternative

> -DW >>> >>>> On Jan 23, 2017, at 9:22 AM, Adrian Zubarev via swift-evolution >>>> wrote: >>>> >>>> +1 for Discourse. Cannot wait any longer for this to happen. >>>> >>>> >>>> >>>> >&

Re: [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse

🎉🎊🎉🎊🎉🎊🎊 This is an awesome decision and a huge enhancement for the Swift community. Thanks (Core Team) for taking the time to entertain the discussion and move forward with what many community members have wanted. Alvarado, Joshua > On Feb 8, 2017, at 5:03 PM, Ted kremenek via swift-evolution

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

The decision to move from the mailing list may have surprised many but the discussion on it has been ongoing very strong. Sorry you feel like you didn't get to voice your opinion which I believe everyone should have the opportunity to. I think many agree that email has it's perks on iPhone and iPad