Re: [swift-evolution] Removing enumerated?

I use enumerated in many location in my code and have never expected it to be indexes but a counting of how many times I have looped. It says clearly what is does on the tin: "Returns a sequence of pairs (n, x), where n represents a consecutive integer starting at zero, and x represents an element

Re: [swift-evolution] Annotation of Warnings/Errors

I feel like warnings showing up as you type are an IDE's responsibility. Annotations to delay warnings seem like noise. Once you get used to programming you don't need the annotations. If warnings are bothersome, then turn it off in the Xcode settings! On Thu, Feb 2, 2017 at 1:34 PM Pierre

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 4:20 PM, Dave Abrahams wrote: > > > on Fri Feb 03 2017, Erica Sadun wrote: > >>> On Feb 3, 2017, at 2:58 PM, Ben Cohen wrote: >>> >>> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution > wrote: > > I don't always make zip a method, but when I do, its argument label is > “to:” Hmm, that doesn’t sound very natural to me. Then again the problem with “zip(with:)" is it’s already kind of

Re: [swift-evolution] Removing enumerated?

I'm in favour of getting rid of enumerated; I think like many people I used it expecting to get actual indices, and it's very easy to think this when working with arrays (as the values will in fact be perfectly valid). In reality the right way to do it is with one of the following: for

Re: [swift-evolution] Removing enumerated?

on Fri Feb 03 2017, Ben Cohen wrote: >> On Feb 2, 2017, at 8:46 PM, Chris Lattner > wrote: >> >> It seems that you are leaning towards removing enumerated(). > > I’m actually kind of conflicted. > > Replacing enumerated() with indexed() feels

Re: [swift-evolution] Removing enumerated?

on Fri Feb 03 2017, Erica Sadun wrote: >> On Feb 3, 2017, at 2:58 PM, Ben Cohen wrote: >> >> >>> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution >>> > wrote: >>> > >>> I believe what people

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 2:58 PM, Ben Cohen wrote: > > >> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution >> > wrote: >> >> I believe what people *want* is `indexed` over `enumerated`, and >>

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 11:12 AM, Erica Sadun via swift-evolution > wrote: > > I believe what people *want* is `indexed` over `enumerated`, and consistently > for both array and array slices. > I don’t know if that’s true. Here’s an example (the only use of

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 3:41 PM, Ben Cohen via swift-evolution > wrote: > > >> On Feb 2, 2017, at 8:46 PM, Chris Lattner > > wrote: >> >> It seems that you are leaning towards removing enumerated(). > > I’m actually

Re: [swift-evolution] Removing enumerated?

> On Feb 2, 2017, at 8:46 PM, Chris Lattner wrote: > > It seems that you are leaning towards removing enumerated(). I’m actually kind of conflicted. Replacing enumerated() with indexed() feels replacing one problem for another. Sometimes people want to number things,

[swift-evolution] Package manager support for versioning (both language and tools)

As part of Swift source compatibility, the Swift compiler added a new flag for controlling what Swift language version should be used to compile with. Currently there is no good way to specify this for Swift packages. We've got a proposal ready that provides a mechanism for controlling this.

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 10:57 AM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Feb 02 2017, Chris Lattner > wrote: > >> On Jan 31, 2017, at 11:16 AM, Ben Cohen via swift-evolution >>

[swift-evolution] [Accepted] SE-0150: Package Manager Support for branches

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md The review of SE-0150 "Package Manager Support for branches" ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to everyone who

[swift-evolution] [Accepted] SE-0149: Package Manager Support for Top of Tree development

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md The review of SE-0149 "Package Manager Support for Top of Tree development" ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to

Re: [swift-evolution] Initializers

> On Jan 31, 2017, at 3:52 AM, Victor Petrescu via swift-evolution > wrote: > > 4. Joe Groff says there is already a backdoor of sorts ("There already is a > backdoor of sorts. This is one of the intended use cases for > implicitly-unwrapped optionals. If you don't

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I'm also +1 on this, wanted this for a long time :) - Dennis > On Feb 2, 2017, at 2:42 PM, Adrian Zubarev via swift-evolution > wrote: > > Great, thanks. Love it :) > > +1 > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Februar 2017 um 14:39:43,

Re: [swift-evolution] Removing enumerated?

on Thu Feb 02 2017, Chris Lattner wrote: > On Jan 31, 2017, at 11:16 AM, Ben Cohen via swift-evolution > wrote: >> >> As we expand (and maybe contract :) the standard library, this kind >> of question comes up a lot, so it is worth

Re: [swift-evolution] for-else syntax

on Fri Feb 03 2017, Dimitri Racordon wrote: > Talking of Python, Swift is not Python and the argument not to > implement a feature because its semantics conflict with the semantics > of a similar looking feature in another language is bogus. I don't have a anything

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 02 2017, Xiaodi Wu wrote: > On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > If indeed the desired semantics for ranges is that they should continue to > lack precise semantics, then an agreement

Re: [swift-evolution] for-else syntax

I'm not really seeing the advantage of `for item in collection else` being discussed or a compelling use case that motivates a language change. You can check the empty case first for empty collections: if collection.isEmpty { ... } else for item in collection { ... } If you're

Re: [swift-evolution] Strings in Swift 4

A bit late, but I agree with Ben on all of this. We could have separate IncompleteRange and InfiniteRange types, and have a consistent world, and even figure out how to get the context-less case to pick InfiniteRange. But we don’t have to, and I don’t think it buys us anything because—as was

Re: [swift-evolution] Subclass Existentials

> On Feb 2, 2017, at 3:24 PM, David Hart wrote: > >> >> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Feb 2, 2017, at 2:54 PM, David Smith >>

Re: [swift-evolution] for-else syntax

I would prefer `ifNone:` instead of `otherwise` as it makes the semantics clearer IMHO. -Thorsten > Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution > : > > >> On 2 Feb 2017, at 13:44, Derrick Ho wrote: >> >> Maybe we can add a

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

> On 2 Feb 2017, at 02:29, Jordan Rose via swift-evolution > wrote: > > For people who would suggest that Swift actually take unsigned integers > seriously instead of using ‘Int’ everywhere, I sympathize, but I think that > ship has sailed—not with us, but with all

Re: [swift-evolution] for-else syntax

> On 2 Feb 2017, at 13:44, Derrick Ho wrote: > > Maybe we can add a new parameter "otherwise" to the forEach method > > [1,2,3,4].forEach({ > // do something > } > , otherwise: { > // do something if it is an empty array > }) That could be a decent compromise; just tried

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

I’m not a fan of moving to a forum or equivalent, however, I’m coming round to the idea. I’d be fine with it as long as the following features were included: * configurable so that I am emailed all new topics and new posts (or RSS equivalent) * Support for markdown, ideally the GitHub dialect

Re: [swift-evolution] for-else syntax

> On 3 Feb 2017, at 09:27, Dimitri Racordon via swift-evolution > wrote: > >> Talking of Python, Swift is not Python and the argument not to implement a >> feature because its semantics conflict with the semantics of a similar >> looking feature in another language

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

One feature is I need the ability to bookmark where I stop reading during the journey or trip. A few contributors keep replying with quoted message ate up my mobile data usage significantly especially this thread is getting a long discussion is hard to read on a small screen and I don't use email

Re: [swift-evolution] for-else syntax

Talking of Python, Swift is not Python and the argument not to implement a feature because its semantics conflict with the semantics of a similar looking feature in another language is bogus. I don’t see the Python for … else being different (and having looked it up to see what you all were

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

> In a mailing list format, everyone is free to start a new thread. Would a forum have a privilege system that stops newbies from starting threads? I've seen no one proposing that. > Whether you invented the language or started learning it yesterday, if you > have a new idea, it comes into