Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Wed, Apr 13, 2016 at 4:45 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: Updated proposal: > > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md I like the use of `location(...)` instead of `index(...)`. I strongly sugges

Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

> You may want to take a peek here:  > https://gist.github.com/erica/a51a981ee0352235204692affa959307 >   > -- E > Thanks for the link, Erica, very informative. The striding(by:) method combined with the (as of yet) non-canonical range types looks great; it also tackles half the problem, since

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

I like this idea. I think, if we could use `self` to access instance of self, we should be allowed to use `Self` to access type of self. 2016-04-14 8:46 GMT+04:00 William Dillon via swift-evolution < swift-evolution@swift.org>: > This would be great! > > I use a nearly identical pattern in my net

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

This would be great! I use a nearly identical pattern in my networking framework that would be nice to streamline: public func ==(lhs: NetworkAddress, rhs: NetworkAddress) -> Bool { // Only addresses of the same protocol are considered equal. guard lhs.dynamicType == rhs.dynamicType else

Re: [swift-evolution] Crypto routines as part of the core library

So what would it take to get a standard set of crypto API's built into the language? Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209) 535-5357 Optimizing Operations for Mobile and Distributed Systems On Apr 13, 2016, at 10:11 AM, David Waite mailto:da...@alkaline-solu

[swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

It's been pitched before, but I don't think we've had a dedicated thread to this idea. Erica has proposed making `Self` generally available within methods in types to refer to the dynamic type of the current receiver. One could think of `Self` as a special associated type member that exists in e

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, plx > wrote: > > Seriously, just because Swift has Optionals and they're useful for > safety in some scenarios (compared with allowing everything to be > null

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 5:36 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, plx wrote: > >>On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Tue Apr 12 2016, plx >> wrote: >> >>Aside: `indices` being irregular c

Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

Hi Vladimir, In the past weeks, I wrote extensively on swift-evolution about an alternative for the classical for-loop. So extensively that it irritated the ”Collectians” who (indirectly) classified me and some similar others as “Forloopians” and also “Traditionalists”… I consider this as a gr

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, Dave Abrahams wrote: > on Mon Apr 11 2016, Nate Cook wrote: > >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md >> >> On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution >> wrote: >> >>

Re: [swift-evolution] [Proposal] mapValues

I don't think I've ever called map on a dictionary in production code, only a mapValue function like this thread discusses. When do we actually want to call map on a dictionary? I feel like mapValue should be the default. I'm wondering if `Dictionary.Element`should be `Value`, instead of `(Key,Val

Re: [swift-evolution] [SR-933] Rename flatten to flattened

With regard to trig they are functions: let s = sin(x) so not really relevant. But if the were made members then: let s = x.sined x.sin() Would read well. On Tuesday, 12 April 2016, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > >> Do you also think that tri

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, plx wrote: >> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Apr 12 2016, Brent Royal-Gordon wrote: >> > >>> In these cases, it would be better if the `successor(of:)` method was >>> designed in a way that acknowledged and encap

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 4:26 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 12 2016, Brent Royal-Gordon wrote: > >> In these cases, it would be better if the `successor(of:)` method was >> designed in a way that acknowledged and encapsulated the bounds check >> that is usually

Re: [swift-evolution] [Proposal] mapValues

on Wed Apr 13 2016, Nate Cook wrote: > On Apr 13, 2016, at 12:02 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > To adhere to the API Design Guidelines, I think it should be named > "mappingValues", right? > > On Wed, Apr 13, 2016 at 4:23 AM, Vladimir.S via swift-ev

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 11 2016, Nate Cook wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your comments, Brent! > > on Sun Apr

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, Tony Parker wrote: >> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Apr 13 2016, Dave Abrahams wrote: >> > Reverse is the best opposite we have of advance, so it makes sense to me. >>> >>> Oh, I get it. >>> O

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, plx wrote: > On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution > wrote: > > on Tue Apr 12 2016, plx > wrote: > > Aside: `indices` being irregular can be a benefit in the context of > auto-complete. > > * What is your eval

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 12:57 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 13 2016, Dave Abrahams wrote: > >>> Reverse is the best opposite we have of advance, so it makes sense to >>> me. >> >> Oh, I get it. >> >>> Or we could use retreat. =) There are other pairs of wor

Re: [swift-evolution] What about a VBA style with Statement?

Well, method cascading might also be an alternative to consider? In Smalltalk this is possible like so: someInstance eat: ‘cookie' print: “Hmmm, that was good!” beHappy singCookiesSong ; In Smalltalk, the semicolon closes the method cascadin

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 5:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Apr 12 2016, plx > wrote: > >> Aside: `indices` being irregular can be a benefit in the context of >> auto-complete. >> >>* What is your evaluation of the proposal? >

Re: [swift-evolution] [Proposal] Safer half-open range operator

on Wed Apr 13 2016, Maximilian Hünenberger wrote: > Should this new operator form a new range? How can this range know about the > array's indices? > > A while ago there was a proposal (unfortunately it was not discussed enough) > which introduced safe array indexing: > > array[safe: 3] // retur

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Tue Apr 12 2016, Brent Royal-Gordon wrote: > Yes, I totally agree that `Collection.subscript(_: Index)` should not > be Optional. > > But I think that index-manipulation methods like `successor(of:)` are > a different story. It is normal and expected that, when you alter an > index, you will

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Tue Apr 12 2016, Patrick Smith wrote: > +1 to Tony’s naming suggestions, myself preferring move(index:by:), move > (indexForward:), and move(indexBackward:) as it is the most clear and > consistent. Sure, any individual operation in a mutating/nonmutating pair can be better named if you don'

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, Dave Abrahams wrote: >> Reverse is the best opposite we have of advance, so it makes sense to >> me. > > Oh, I get it. > >> Or we could use retreat. =) There are other pairs of words that work >> as well, like “increment/decrement”. > > Yeah, unfortunately those carry an in

Re: [swift-evolution] [Proposal] Safer half-open range operator

Another common application would be on pagination systems. For example, this function that I just found randomly: https://github.com/MrAlek/PagedArray/blob/bf64cbb140cf8bd109483dd749ac40a5f4531dfd/Source/PagedArray.swift#L88 public func indexes(pageIndex: Int) -> Range { assert(pageIndex >= s

Re: [swift-evolution] What about a VBA style with Statement?

I think the idea is good, but I think it would be bad for the language overall. -1 As a plus, it makes code easier to write, sometimes; or at least it seems so. On the other hand, I think it makes code harder to comprehend. A `with` statement introduces a new scope in which it is not obvious wh

Re: [swift-evolution] [Proposal] mapValues

on Tue Apr 12 2016, Jonathan Hull wrote: > I would really like to see something like the following added to the standard > library: > > extension Dictionary { > > func mapValues(transform:(Key,Value)->U)->[Key:U] { > var output:[Key:U] = [:] > for (k,v) in self { > output[k] = transform(k,v) > }

Re: [swift-evolution] [Proposal] Safer half-open range operator

On 13.04.2016 19:59, Pyry Jahkola wrote: On 13 Apr 2016, at 17:53, Luis Henrique B. Sousa mailto:lshso...@gmail.com>> wrote: (…) I totally agree with @Vladimir that we could have a more clear and /swift-ly/ way to concisely wrap those operations. The behaviour pointed out by him looks very nic

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 13 2016, Tony Parker wrote: > On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your review, Tony! > > on Mon Apr 11 2016, Tony Parker wrote: > > On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >

Re: [swift-evolution] [Proposal] mapValues

> On Apr 13, 2016, at 12:02 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > To adhere to the API Design Guidelines, I think it should be named > "mappingValues", right? > > On Wed, Apr 13, 2016 at 4:23 AM, Vladimir.S via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > A

[swift-evolution] [Deferred] SE-0058 Allow Swift types to provide custom Objective-C representations

The review of SE-0058 "Allow Swift types to provide custom Objective-C representations" ran from April 4...11, 2016. The proposal has been deferred from Swift 3. We agree that it would be valuable to give library authors the ability to bridge their own types from Objective-C into Swift using the

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 12, 2016, at 2:32 PM, Dietmar Planitzer via swift-evolution > wrote: > > Inline. > >> On Apr 11, 2016, at 10:03, Dave Abrahams wrote: >> >> >> on Sun Apr 10 2016, Dietmar Planitzer wrote: >> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >>> wrote:

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

on Wed Apr 13 2016, Douglas Gregor wrote: > On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution > wrote: > > I wouldn't mind driving the discussion and proposal, because I'd really > like > to see a more complete generics system. Before I start, can David or Doug, >

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: > > To me, compound names for closure properties and satisfying property > requirements with methods aren't hacks, they're missing features we ought to > support anyway. Hello, I may have missed the point, but it looks li

Re: [swift-evolution] What about a VBA style with Statement?

On 13.04.2016 19:48, Erica Sadun wrote: > My version of `with` doesn't have this issue. However, it's a clear logical error on the programmer's part when you treat a value type as a reference type. Could you provide your 'with' function please?(checked last emails - can't find) Right now it i

Re: [swift-evolution] Crypto routines as part of the core library

I don’t know if we need a boost-like parent project in order to start building core code to be brought for inclusion. I think success will naturally bring such a project structure - people seeking a curated and integrated set of frameworks to get common functionality. -DW > On Apr 13, 2016, a

Re: [swift-evolution] [Proposal] mapValues

To adhere to the API Design Guidelines, I think it should be named "mappingValues", right? On Wed, Apr 13, 2016 at 4:23 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > As for mapKeys and many values into a single key. I believe we should have > a choice - do we expect mul

Re: [swift-evolution] [Proposal] Safer half-open range operator

> On 13 Apr 2016, at 17:53, Luis Henrique B. Sousa wrote: > > (…) I totally agree with @Vladimir that we could have a more clear and > swift-ly way to concisely wrap those operations. > > The behaviour pointed out by him looks very nice and doable to me. > > a = [1,2,3] > a[-1..<6] - raises ru

Re: [swift-evolution] What about a VBA style with Statement?

On 13.04.2016 18:09, Radosław Pietruszewski wrote: I’m -1, at least in the foreseeable future. I do agree that this is a useful construct, but if I can do it in library code, paying only a small price for this, I’d prefer Swift to grow better in places that a library *can’t* fix. Well, there a

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 12, 2016, at 11:24 PM, Douglas Gregor wrote: > > >> On Apr 11, 2016, at 10:15 AM, Joe Groff wrote: >> >> >>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> One could perhaps work around (a), (b), and (d) by allowing compound >>> (function-like)

Re: [swift-evolution] What about a VBA style with Statement?

> On Apr 13, 2016, at 10:32 AM, Vladimir.S wrote: > > But in case of struct instance constant - we have a problem: > > struct A { >var x = 1 >var y = 2 > } > > let a1 = A() > > with (a1) { >print($0.x) >$0.y = 10 > } > > - this will be compiled without errors/warnings, but ye

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 10:30 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> One could perhaps work around (a), (b)

Re: [swift-evolution] What about a VBA style with Statement?

But in case of struct instance constant - we have a problem: struct A { var x = 1 var y = 2 } let a1 = A() with (a1) { print($0.x) $0.y = 10 } - this will be compiled without errors/warnings, but yes - there will be runtime error. I'm sure this is not what we need from Swift.

Re: [swift-evolution] Crypto routines as part of the core library

So what are developers doing then to make sure their apps are secure? Are they just not adopting Swift, or just relying on the bridging of CommonCrypto to fill the gaps? Travis Beech | Principal Developer | Unwired Revolution | c: 1 (209) 535-5357 Optimizing Operations for Mobile and Distributed

Re: [swift-evolution] Crypto routines as part of the core library

> This seems like a great candidate for a library that could be developed in > the community and then possibly brought into Corelibs in a future version true — but sadly, there seems to be either no interest or manpower for a boost-like infrastructure… Like many other fundamental topics, I don't

Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

as @Erica just noted, we probably will have this in Swift3 : for i in (1...10).striding(by: 3) {..} for i in (1...10).striding(by: -3) {..} But.. compare how the next is more clear and nice looking, has less noise, how faster this will be typed.. : for i in 1...10 by 3 {...} for i in 1...10 b

Re: [swift-evolution] What about a VBA style with Statement?

> On Apr 13, 2016, at 9:34 AM, Kurt Werle via swift-evolution > wrote: > > I've always thought that the with construct is not a good idea. It seems to > me that the moment you want to use with it indicates that you are getting too > much into some other classes business; shouldn't that class

Re: [swift-evolution] Crypto routines as part of the core library

With the focus these days on writing secure applications it seems building this functionality into the language would be pretty high on the list. These are common API's found in modern languages and it would be nice to not have to use hackish techniques like bridging into CommonCrypto to achieve

Re: [swift-evolution] What about a VBA style with Statement?

> On Apr 13, 2016, at 7:50 AM, Benzi via swift-evolution > wrote: > > The closest right now you can achieve would be: > > func with(item:T, apply:(T)->Void) { > apply(item) > } > > > let label = UILabel() > label.highlighted // defaults to false > > with(label) { > $0.highlighted =

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 3:43 PM, Dave Abrahams via swift-evolution > wrote: > > > Thanks for your review, Tony! > > on Mon Apr 11 2016, Tony Parker > wrote: > >>> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> Hello Swift

[swift-evolution] What about a VBA style with Statement?

The closest right now you can achieve would be: func with(item:T, apply:(T)->Void) { apply(item) } let label = UILabel() label.highlighted // defaults to false with(label) { $0.highlighted = true } label.highlighted // is now true ___ swift-e

Re: [swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

You may want to take a peek here: https://gist.github.com/erica/a51a981ee0352235204692affa959307 -- E > On Apr 13, 2016, at 8:52 AM, Hans Huck via swift-evolution > wrote: > > Rationale: > > Swift's For-In-loop is fine, as long as you don't need an iteration step size > other than 1/-1, in

Re: [swift-evolution] What about a VBA style with Statement?

Because many APIs use configuration/partial initialisation patterns. Look at Metal for example. But I agree that most of the time, its not such a big deal. — Taras > On 13 Apr 2016, at 17:34, Kurt Werle wrote: > > I've always thought that the with construct is not a good idea. It seems to

Re: [swift-evolution] What about a VBA style with Statement?

I've always thought that the with construct is not a good idea. It seems to me that the moment you want to use with it indicates that you are getting too much into some other classes business; shouldn't that class deal with this? Why are you exposing/integrating so much of some other class's logi

Re: [swift-evolution] What about a VBA style with Statement?

+1 on statement vs lexical scope. additionally { $0.something ... } is more explicit than just .something. On 13.04.2016 17:36, Taras Zakharko via swift-evolution wrote: We had this kind of proposal earlier, didn’t seem to be very well received. I still think it would be a useful thing, but I’

Re: [swift-evolution] What about a VBA style with Statement?

> On 13 Apr 2016, at 16:47, Vladimir.S wrote: > > Than you for sharing this method. So, do you suggest to not have this "with" > construction in Swift just because we *can* implement the same behavior by > using some workarounds/hacks? > > I.e. do you support this proposal or don't? > Do you a

Re: [swift-evolution] What about a VBA style with Statement?

Yes, it really looks like language construction, and I like this approach. with (some) { $0... = ... } But should many of us copy-paste these functions in each module/project or this is very handful feature that we want to have in our language? What do you think about the proposal? Actually

Re: [swift-evolution] [Proposal] Safer half-open range operator

Many thanks @Pyry, it's great to see those changes coming in swift 3. The examples using *clamp* you mentioned here would do what I'm proposing, but I totally agree with @Vladimir that we could have a more clear and *swift-ly* way to concisely wrap those operations. The behaviour pointed out by hi

Re: [swift-evolution] What about a VBA style with Statement?

Than you for sharing this method. So, do you suggest to not have this "with" construction in Swift just because we *can* implement the same behavior by using some workarounds/hacks? I.e. do you support this proposal or don't? Do you agree that such built-in feature will be very useful and make

[swift-evolution] [Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop

Rationale:   Swift's For-In-loop is fine, as long as you don't need an iteration step size other than 1/-1, in which case it becomes unexpectedly inconsistent and unwieldy.   for i in 1...10 for i in reverse(10...1) for i in stride(from:1, through:10, by:3) or even for i in 1.stride(through:10

Re: [swift-evolution] What about a VBA style with Statement?

We had this kind of proposal earlier, didn’t seem to be very well received. I still think it would be a useful thing, but I’d do it as a statement (extension of do) that introduces new lexical scope (similar to self) — Taras > On 13 Apr 2016, at 16:25, Sean Heber via swift-evolution > wrote:

Re: [swift-evolution] What about a VBA style with Statement?

This pair works pretty well, too, if you don’t mind free functions: func with(inout this: T, @noescape using: inout T->Void) { using(&this) } func with(this: T, @noescape using: T->Void) { using(this) } It works either with classes or mutable structs if you call it correctly and the type doesn’t

Re: [swift-evolution] What about a VBA style with Statement?

It can be (more-or-less) solved in library code today: extension NSObjectProtocol { public func with(@noescape fn: Self -> Void) -> Self { fn(self) return self } } This way, you can do, on NSObjects: textLabel.with { $0.textAlignment = .Left $0.textColor =

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 13, 2016, at 5:34 AM, Haravikk wrote: > > >> On 13 Apr 2016, at 04:46, plx via swift-evolution >> wrote: >> >> Invalidation is hard and I wouldn’t want anything held up to try and find a >> solution first. > > Oh I agree, that was partly my point though; while this proposal may le

Re: [swift-evolution] What about a VBA style with Statement?

I like this idea. In Delphi(Pascal) there is also such construction with someVar do begin end; And it is very handy and is used a lot (usually if you need to set/read a lot of properties of some object). Additionally, I believe such construction prevents some possible mistakes with used var

[swift-evolution] What about a VBA style with Statement?

I recently learned some VBA and I found a very conveniently `with` statement. `with` statement can be helpful to set property for UIKit instance. for instance a UILabel instance `textLabel` ,with `with` statement we can set UILabel property like this ```swift with textLabel{ .textAlignment =

Re: [swift-evolution] [Proposal] Safer half-open range operator

Is it really great to have a[a.indices.clamped(to: 0 ..< 5)] instead of a clear a[truncate: 0 ..< 5] ? and if it is not "a" but "arrayOfSomeValues" we have arrayOfSomeValues[arrayOfSomeValues.indices.clamped(to: 0 ..< 5)] Don't feel this is nice. Is it really so wrong to have additional(to "direc

Re: [swift-evolution] [Proposal] Safer half-open range operator

The problem the "a[i &..< j]" is trying to solve is to allow us to work with array bounds without errors, even if i/j is incorrect, when we explicitly allows this. As for your question, yes, it seems like there is a problem :-) "i &..< j" should become a new Range. But such range knows nothing

Re: [swift-evolution] [Proposal] mapValues

As for mapKeys and many values into a single key. I believe we should have a choice - do we expect multiply values for the same key or not. Just like "+" and integer overflow : by default it raises the error, but if "&+" - we expect the overflow. I can imagine situations when it is ok for me to

Re: [swift-evolution] [Proposal] Safer half-open range operator

> On 11 Apr 2016, at 15:23, Luis Henrique B. Sousa via swift-evolution > wrote: > let a = [1,2,3] > let b = a[0..<5] > print(b) > In the swift-3-indexing-model branch , you can clamp a range just li

Re: [swift-evolution] [Proposal] Safer half-open range operator

Should this new operator form a new range? How can this range know about the array's indices? A while ago there was a proposal (unfortunately it was not discussed enough) which introduced safe array indexing: array[safe: 3] // returns nil if index out of bounds So another way to handl

Re: [swift-evolution] [Proposal] mapValues

+1 on mapValues. DictionaryLiteral already throws an exception if it includes duplicate keys, so I'd expect mapKeys to throw an error if multiple source keys mapped to the same destination key. On Wed, Apr 13, 2016 at 11:28 AM, Miguel Angel Quinones via swift-evolution wrote: > I'm +1 for addin

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On 13 Apr 2016, at 04:46, plx via swift-evolution > wrote: > > Invalidation is hard and I wouldn’t want anything held up to try and find a > solution first. Oh I agree, that was partly my point though; while this proposal may leave us with the "un-Swifty" issue of being unable to explicitl

Re: [swift-evolution] [Proposal] mapValues

I'm +1 for adding mapValues. Very useful functionality and trivial to implement.  > > I.e. I suggest to implement and mapKeys() also. It could be also useful in > > some situations. > `mapKeys` is much more dangerous, because you could end up mapping many > values into a single key. You kind of

Re: [swift-evolution] [Proposal] mapValues

> I.e. I suggest to implement and mapKeys() also. It could be also useful in > some situations. `mapKeys` is much more dangerous, because you could end up mapping many values into a single key. You kind of need to combine the values somehow. Perhaps: extension Dictionary {

Re: [swift-evolution] [Proposal] mapValues

+1 for this. Highly useful method and imo should be implemented for Dictionary. And what if we need to transform the key? For ex. we have var d = ["1" : "abc", "2" : "def"] we could have such method: d.mapKeys {k,v -> Int in Int(k)! } to get: [2: "abc", 1: "def"] I.e. I suggest to implement and

Re: [swift-evolution] [Proposal] mapValues

> I would really like to see something like the following added to the standard > library: > > extension Dictionary { > > func mapValues(transform:(Key,Value)->U)->[Key:U] { > var output:[Key:U] = [:] > for (k,v) in self { > output[k] = transform(k,v) >

Re: [swift-evolution] [Proposal] mapValues

“map” already "maps the values” so I think something like “transform” might be a little clearer, if we don’t want to just overload “map”. Regardless of what it’s called, though, I’m +1 on the functionality. - Dave Sweeris > On Apr 13, 2016, at 1:41 AM, Jonathan Hull via swift-evolution > wrot

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

What about this? I’m unfamiliar with the details of objc-swift interoperability, so I’m not actually sure it could work this way, nor am I certain that I’m not just “rephrasing” something that’s already been suggested. protocol SomeProtocol { //Non-optional stuff goes here } extension SomePro

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution > wrote: > > I wouldn't mind driving the discussion and proposal, because I'd really like > to see a more complete generics system. Before I start, can David or Doug, or > someone else with a high-level view of the generics system