Re: [swift-evolution] Default Generic Arguments

> If the answer to the above question is "yes, T is inferred as Int" then we need some way to express "give me the default for T, which is Float." I don't think that we need that. It would introduce a new level of explicitness, "I want the default, but I don't care what the default is", that is no

Re: [swift-evolution] Reduce with inout

I've thought about it for a few days, and really like `reduce(mutating:_)`. I've updated the PR, and am now happy for this to go into review. https://github.com/apple/swift-evolution/pull/587 On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop wrote: > > On Jan 22, 2017, at 10:56 PM, Chris Eidhof wro

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution > wrote: > >> >> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado >> > wrote: >>> >>>

Re: [swift-evolution] Strings in Swift 4

Seems like a good solution to me. > On 24 Jan 2017, at 05:29, Gwendal Roué via swift-evolution > wrote: > > >> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution >> a écrit : >> The operands and sense of the comparison are kind of lost in all this garbage. You reall

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

> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution > wrote: > > We're not terribly principled about this right now with non-pattern > declaration references. You can still reference an unapplied function by its > base name alone without its labels, if it's unambiguous: > > func foo(x

[swift-evolution] A case for postponing ABI stability

Hello swift-evolution, ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 23, 2017, at 9:50 AM, Ben Cohen wrote: > > >> On Jan 22, 2017, at 9:54 PM, Félix Cloutier wrote: >> >> doesn't necessarily mean that ignoring that case is the right thing to do. In fact, it means that Unicode won't do anything to protect programs

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 23, 2017, at 7:49 AM, Joshua Alvarado > wrote: > > 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

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 23, 2017, at 4:08 AM, Karl Wagner wrote: > > >> On 23 Jan 2017, at 06:54, Félix Cloutier via swift-evolution >> wrote: >> >> doesn't necessarily mean that ignoring that case is the right thing to do. In fact, it means that Unicode won't do anything to

Re: [swift-evolution] Strings in Swift 4

> Le 24 janv. 2017 à 05:29, Gwendal Roué a écrit : > > >> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> The operands and sense of the comparison are kind of lost in all this garbage. You really want to see `foo <

Re: [swift-evolution] Strings in Swift 4

> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution > a écrit : > >>> The operands and sense of the comparison are kind of lost in all this >>> garbage. You really want to see `foo < bar` in this code somewhere, but you >>> don't. >> >> Yeah, we thought about trying to build a

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

Sent from my iPad > On Jan 23, 2017, at 8:48 PM, Karl Wagner wrote: > > >>> On 24 Jan 2017, at 01:03, Joe Groff via swift-evolution >>> wrote: >>> >>> On Jan 23, 2017, at 4:00 PM, Matthew Johnson wrote: > On Jan 23, 2017, at 5:52 PM, Joe Groff wrote: > >>

Re: [swift-evolution] Default Generic Arguments

While it looks nicer without the angle brackets, that suggestion is unresponsive to David's point that we need some way to distinguish defaulted generic arguments from inferred generic arguments. Consider: ``` let a: Optional = 1 // Optional enum FloatPreferringOptional { case some(T) case no

Re: [swift-evolution] Strings in Swift 4

> On Jan 21, 2017, at 3:49 AM, Brent Royal-Gordon > wrote: I'm going to trim out the bits where my answer is an uninteresting "Good" or "Okay, we'll leave that for later" or what-have-you. >> The operands and sense of the comparison are kind of lost in all this >> garbage. You really want to

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

> On 24 Jan 2017, at 01:03, Joe Groff via swift-evolution > wrote: > >> >> On Jan 23, 2017, at 4:00 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 23, 2017, at 5:52 PM, Joe Groff >> > wrote: >>> On Jan 23, 2017, at 3:49 PM,

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

This was previously pitched. https://lists.swift.org/pipermail/swift-evolution/2015-December/000231.html Here was the use-case that led to the thread being abandoned: https://gist.github.com/stevestreza/2557dc5ec9e7c

Re: [swift-evolution] Default implementation of protocols

Ok, I could get behind that. Especially if we get factory initializers on protocols… Thanks, Jon > On Jan 23, 2017, at 5:57 PM, Karl Wagner wrote: > > >> On 24 Jan 2017, at 01:13, Jonathan Hull via swift-evolution >> wrote: >> >> Have we considered allowing a struct/class/enum to have the

Re: [swift-evolution] Default implementation of protocols

> On 24 Jan 2017, at 01:13, Jonathan Hull via swift-evolution > wrote: > > Have we considered allowing a struct/class/enum to have the same name as a > protocol as long as it conforms to the protocol? Type declarations would > have to always mean the protocol (which includes the concrete typ

Re: [swift-evolution] Default implementation of protocols

Moreover, how would you extend the protocol? On Mon, Jan 23, 2017 at 19:51 Xiaodi Wu wrote: > No, I don't think so. How would you declare a variable of type X, meaning > the protocol? > On Mon, Jan 23, 2017 at 19:49 Jonathan Hull wrote: > > I agree with your point on classes, so maybe just value

Re: [swift-evolution] Default implementation of protocols

No, I don't think so. How would you declare a variable of type X, meaning the protocol? On Mon, Jan 23, 2017 at 19:49 Jonathan Hull wrote: > I agree with your point on classes, so maybe just value types would be > allowed to do it (I have only wanted it for structs myself). I think I > answered

Re: [swift-evolution] Default implementation of protocols

I agree with your point on classes, so maybe just value types would be allowed to do it (I have only wanted it for structs myself). I think I answered your comment about distinguishing between existential and struct X if you re-read my original message. Thanks, Jon > On Jan 23, 2017, at 5:10

Re: [swift-evolution] Default implementation of protocols

This would get very confusing, as it would be impossible for a class to distinguish conforming to protocol X vs. inheriting from base class X, or else we would have to change the spelling for that as well. Moreover, you would have no way of distinguishing the existential X from the struct X. I see

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

We will, but we can't do any rewriting of anything until Swifts server library is up and running, which I believe it is not (feel free to correct me if I am wrong). I'll go a little further and give a +4 for discourse. Or anything else. My email is filled with a total of 13808 e-mails. 141 of those

Re: [swift-evolution] Default Generic Arguments

This proposal looks good to me. I have been looking forward to more flexible generic arguments for a while. I agree with previous commenters who prefer the option to leave off the angle brackets when all parameters have defaults. The proposal specifically mentions that the syntax is inspired b

[swift-evolution] Default implementation of protocols

Have we considered allowing a struct/class/enum to have the same name as a protocol as long as it conforms to the protocol? Type declarations would have to always mean the protocol (which includes the concrete type as well). Static functions would always apply to the concrete type. Seems like

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

> On Jan 23, 2017, at 6:03 PM, Joe Groff wrote: > > >> On Jan 23, 2017, at 4:00 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 23, 2017, at 5:52 PM, Joe Groff >> > wrote: >>> On Jan 23, 2017, at 3:49 PM, Matthew Johnson >>>

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

> On Jan 23, 2017, at 4:00 PM, Matthew Johnson wrote: > >> >> On Jan 23, 2017, at 5:52 PM, Joe Groff > > wrote: >> >>> >>> On Jan 23, 2017, at 3:49 PM, Matthew Johnson >> > wrote: >>> >>> >>> >>> Sent from my iPad >>> >>> On Jan 23,

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

> On Jan 23, 2017, at 5:52 PM, Joe Groff wrote: > >> >> On Jan 23, 2017, at 3:49 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>>

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

> On Jan 23, 2017, at 4:00 PM, Matthew Johnson wrote: > > >> On Jan 23, 2017, at 5:52 PM, Joe Groff > > wrote: >> >>> >>> On Jan 23, 2017, at 3:49 PM, Matthew Johnson >> > wrote: >>> >>> >>> >>> Sent from my iPad >>> >>> On Jan 23, 2

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 4:27 PM, Joe Groff via swift-evolution > wrote: > > >> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado >> > wrote: >>> >>>

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

> On Jan 23, 2017, at 3:49 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> This looks pretty good! It might be worth calling out explicitly that >> matching a payloaded case

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

> On Jan 23, 2017, at 09:59, Joshua Alvarado via swift-evolution > wrote: > > It will be painted! ;) > > So far we have: > +2 Disclosure > +1 Slack > +1 Issue tracker > > Let's really get everyone's opinions and see if we can get this rock rolling > towards a better solution. Of course it w

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

Sent from my iPad > On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution > wrote: > > This looks pretty good! It might be worth calling out explicitly that > matching a payloaded case by name alone still works, e.g.: > > enum Foo { case foo(Int), bar(x: Int) } > > switch Foo.foo(0) {

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

Obligatory prior discussion sheds, er, I mean threads: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025692.html / https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/th

[swift-evolution] Fwd: re: [Discussion] mailing list alternative

-- Forwarded message -- From: Ethin Probst Date: Mon, 23 Jan 2017 15:43:59 -0600 Subject: Re: [swift-evolution] [Discussion] mailing list alternative To: Joshua Alvarado If you guys desire it, I'd be happy to host a forum for you all. You'll have to give me a weak or two to get i

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

Another +1 for Discourse. I'd like to participate more, but the mailing list format is difficult for me to use. I've gone through three email clients since swift-evolution started (Apple Mail, then Airmail, and now Spark), and they work well enough for general, simple email usage, but the maili

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution > wrote: > > >> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado > > wrote: >> >> Taken from NSHipster : >> Happily, on one thing we can all agree. In NSRegula

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

We could mark it as high priority. ;) But yes you are correct. Keeping a poll and a count won't do any good if Apple won't actually change the infrastructure. This topic is for an official change and not an spun up chat room. I do believe that if the issue is strong then it may be heard but if

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

Added to the “Source Compatibility” section https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Normalize-Enum-Case-Representation.md > On Jan 23, 2017, at 1:32 PM, Joe Groff wrote: > > This looks pretty good! It might be worth calling out explicitly that

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado > wrote: > > Taken from NSHipster : > Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has the > most long-winded and byzantine regular expression interface you’re ever > likely to c

Re: [swift-evolution] Default Generic Arguments

A `Parser where StringType : ParsableStringType` `Void` is a fine default (somewhat questionable but follow me) because `Void?` ends up having the same info as a boolean which means that our Parser is, effectively, a recognizer. Thinking about it, `GrammarRecognizer where StringType : ParsableStri

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

I meant more that we are dependent on Apple to actually change the existing official infrastructure to some new system. If all we want is an unofficial forum, any one of us could set that up now and invite people over for talk and snacks. I assume swift-evolution is more of a meritocracy than a

Re: [swift-evolution] Default Generic Arguments

I think I like the explicitness of a required <> as well. (It reminds me of Java, where you can leave out the parameter when the type is known.) I am however not sure if we could add this without breaking current valid Swift 3 syntax. The following three statements are correct in Swift 3:

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 3:08 PM, Sean Heber via swift-evolution > wrote: > > >>> * The talk about implicit conversions between Substring and String bums me >>> out, even though I see the importance of it in this context and know that >>> it outweighs the alternatives. Given that the Swift team s

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

I’ve incorporated feedbacks from this thread. Rendered: https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Normalize-Enum-Case-Representation.md

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

+ 3 Disclosure + 1 Slack + 1 Issue Tracker Jarod, I completely agree on your points. Changing from email threads will help participation and tracking threads. The email threads work in favor for those who have figured out how to use them. I am usually seeing only the same people participating

Re: [swift-evolution] Default Generic Arguments

You do have empty angle brackets today, which indicate an inferred generic argument rather than a defaulted generic argument. See: 1> let a = 1 a: Int = 1 2> let b:Optional = a b: Int? = 1 If Swift had defined Optional as Optional, statement 2 would be ambiguous. I have a hard time coming

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

This looks pretty good! It might be worth calling out explicitly that matching a payloaded case by name alone still works, e.g.: enum Foo { case foo(Int), bar(x: Int) } switch Foo.foo(0) { case .foo: break case .bar(x:): break } -Joe > On Jan 23, 2017, at 11:38 AM, Daniel Duan wrote: > >

Re: [swift-evolution] Default Generic Arguments

> On Jan 23, 2017, at 3:18 PM, Srđan Rašić via swift-evolution > wrote: > > > I think such cases would be extremely rare and one would have to be very > ignorant about the types he/she works with. Additionally, that syntax is > useful only for types with one generic argument. Say we have `Pr

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

> On Jan 19, 2017, at 5:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 19 2017, Douglas Gregor wrote: > >> My apologies for the broken link: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md >> >> - Doug > > +

Re: [swift-evolution] Default Generic Arguments

@doug: > struct X { } > func f1() -> X { return X() } > func f2() -> X { return X() } > func f2() -> X { return X() } > func f3(_: T) -> X { return X() } > let x1: X = f1() // okay: x1 has type X? Agreed. When type is explicitly defined in the context, that type should override the default

[swift-evolution] Swift 4 Package Manager Roadmap

Hello Swift Package Manager community, The package manager's release in Swift 3 was a big success, with many enthusiastic adopters. Since then we've been hard at work building the next version of the package manager. We have a lot we want to do, but focus is important for building a successful

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

Some thoughts inline. > On Jan 21, 2017, at 11:06 AM, Daryle Walker via swift-evolution > wrote: > > 1. Variadic generics > > When I look at SwiftDoc.org , I see some functions > repeated with differing numbers of parameters. This seems like a job for > variadic templat

Re: [swift-evolution] Default Generic Arguments

I too agree that empty angle brackets are redundant because the information they convey is not useful enough to justify the syntax clutter. I would value clean syntax in this case more than explicitness and I think that would go along with Swift's philosophy. I would compare this to Swift's type in

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

Obligatory prior discussion sheds, er, I mean threads: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025692.html / https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/thre

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

Helps confirm the need of this change even more. Seems moving over is something many would like and it won't causing any source-breaking changes :) On Mon, Jan 23, 2017 at 12:53 PM, Jacob Bandes-Storch wrote: > Obligatory prior discussion sheds, er, I mean threads: > > https://lists.swift.org/pi

Re: [swift-evolution] Default Generic Arguments

> On Jan 23, 2017, at 10:41 AM, Trent Nadeau via swift-evolution > wrote: > > The proposal looks good to me with one possible concern. I'm leaning toward > types that use the defaults should still require the angle brackets, X<>. > This makes it clear that you're using a generic type. What a

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

> On Jan 22, 2017, at 8:30 AM, Tony Allevato via swift-evolution > wrote: > > Which is another reason we should be auto-deriving Equatable. > > Couldn't variation generics help here? If someone wanted to capture the whole > argument list as a single tuple, we could require that they do it as

Re: [swift-evolution] Default Generic Arguments

I agree. I don’t think empty angle brackets convey anything useful to the reader. l8r Sean > On Jan 23, 2017, at 1:25 PM, T.J. Usiyan via swift-evolution > wrote: > > I am against requiring empty angle brackets. I could live with it either way, > but I think that one reason to provide defau

Re: [swift-evolution] Default Generic Arguments

The fact that it has a default generic argument means that it has a "knob" to turn based on changes in needs of the code. For example, if you had a struct that used a T (defaulted to Int) for a field, and that field's range should become a Double in your use case, you know that there's something yo

Re: [swift-evolution] Default Generic Arguments

I am against requiring empty angle brackets. I could live with it either way, but I think that one reason to provide default types is to hide the detail that there is a type parameter until such a time as it is needed. Empty angle brackets call attention to the feature in a manner that discards any

Re: [swift-evolution] Default Generic Arguments

The proposal looks good to me with one possible concern. I'm leaning toward types that use the defaults should still require the angle brackets, X<>. This makes it clear that you're using a generic type. That leads me to think that the examples Doug gave should be an error as the explicit types on

Re: [swift-evolution] Default Generic Arguments

> On Jan 23, 2017, at 9:51 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Everyone, >> >> I've opened a PR (https://github.com/apple/swift-evolution/pull/591 >>

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

It will be painted! ;) So far we have: +2 Disclosure +1 Slack +1 Issue tracker Let's really get everyone's opinions and see if we can get this rock rolling towards a better solution. Of course it will be Apple's choice in the end but we can give a voice on the matter to show we do care about m

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

As long as we are pretending this bike shed is getting painted again… I would actually prefer something closer to an issue tracker than discourse. We get a lot of repeat and diverging topics, and it would be nice to mark discussions as related, duplicates, etc -DW > On Jan 23, 2017, at 9:22 AM

Re: [swift-evolution] Default Generic Arguments

> On Jan 23, 2017, at 7:55 AM, Srđan Rašić via swift-evolution > wrote: > > Hi Everyone, > > I've opened a PR (https://github.com/apple/swift-evolution/pull/591 > ) proposing default > generic arguments which I think would be nice addition t

Re: [swift-evolution] Generic Subscripts

This can be made typesafe if the ObjectIdentifier of the archetype is stored with the key and checked on retrieval. ~Robert Widmann 2017/01/23 11:43、Thorsten Seitz via swift-evolution のメッセージ: > > >> Am 14.01.2017 um 14:50 schrieb Gwendal Roué via swift-evolution >> : >> > Where generi

Re: [swift-evolution] Generic Subscripts

> Where generic subscripts are concerned, there are a couple of different > things to express: > - Generic parameter (I can understand various co-ordinates for the data) > - Generic return type (I can construct your preferred representation of > the data) > - Generic sett

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

Mobile support would be a must have. I love that Disclosure has good mobile support. Also Slack has added threads and would be a very helpful feature in the way proposals are discussed here. Alvarado, Joshua > On Jan 23, 2017, at 9:22 AM, Adrian Zubarev > wrote: > > +1 for Discourse. Cann

Re: [swift-evolution] Generic Subscripts

> Am 14.01.2017 um 14:50 schrieb Gwendal Roué via swift-evolution > : > Where generic subscripts are concerned, there are a couple of different things to express: - Generic parameter (I can understand various co-ordinates for the data) - Generic return type (I can construc

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

I agree with you, but those recommendations are chat clients, which sound even worse than email for the kind of discussions we have had on the mailing list. Discourse is my pick. > On 23 Jan 2017, at 17:02, Joshua Alvarado via swift-evolution > wrote: > > Hey swifters, > I would like to (re

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

+1 for 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 to (re)open up discussion on moving away from email for the

[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] 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] Default Generic Arguments

Hi Everyone, I've opened a PR (https://github.com/apple/swift-evolution/pull/591) proposing default generic arguments which I think would be nice addition to the language. They are also mentioned in "Generic manifesto". The proposal is focusing around generic types. Generic functions are not cove

Re: [swift-evolution] Reduce with inout

To me, that sounds more like a monomorphic map? (i.e. a `map` that doesn't change the type). On Mon, Jan 23, 2017 at 10:07 AM, Jonathan Hull wrote: > While we are at it, could we add a inout/mutating version of forEach > (unless something like that exists and I missed it)? I have been trying to

Re: [swift-evolution] Strings in Swift 4

> On 23 Jan 2017, at 06:54, Félix Cloutier via swift-evolution > wrote: > > >>> doesn't necessarily mean that ignoring that case is the right thing to do. >>> In fact, it means that Unicode won't do anything to protect programs >>> against these, and if Swift doesn't, chances are that no one

Re: [swift-evolution] Reduce with inout

While we are at it, could we add a inout/mutating version of forEach (unless something like that exists and I missed it)? I have been trying to figure out how to run through an array and call a mutating method on each element without copying everything, and I am at a loss… Thanks, Jon > On J