Re: [swift-evolution] [Proposal] Random Unification

> Le 26 sept. 2017 à 16:14, Xiaodi Wu a écrit : > > On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier > wrote: > > It's possible to use a CSPRNG-grade algorithm and seed it once to get a > reproducible

Re: [swift-evolution] Question about async await

-Pierre > On Sep 26, 2017, at 1:57 PM, Jean-Daniel wrote: > > > >> Le 26 sept. 2017 à 22:38, Pierre Habouzit > > a écrit : >> >>> On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution >>>

Re: [swift-evolution] Re-pitch: remove(where:)

All very good points. > On Sep 26, 2017, at 10:32 PM, Xiaodi Wu wrote: > >> On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett >> wrote: >> formFilter reads really weirdly... the use of filter in `filter` is not as a >> noun, but as a verb — compare

Re: [swift-evolution] Re-pitch: remove(where:)

On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett wrote: > formFilter reads really weirdly... the use of filter in `filter` is not as > a noun, but as a verb — compare to e.g., formRemainder. Calling formFilter > won’t create a filter, it will “do” a filter. Perhaps

Re: [swift-evolution] [Proposal] Random Unification

First of all, I like this proposal. For a empty RandomAccessCollection, is it cause a fatal error with calling the random methods? > Alejandro Alonso via swift-evolution 於 2017年9月26日 > 下午12:57 寫道： > > Hello evolution, > > I am very thankful for all the feedback,

Re: [swift-evolution] [Proposal] Random Unification

To throw an idea out into the wild: How about a protocol to define the default source fo random on a given platform, with per-platform extensions to provide default implementations? This would allow any eventual proposal to have default arguments for functions— or to use within `var`s— without

Re: [swift-evolution] Idea: using 'super()' as syntactic sugar for 'super.overriddenmethod(...)'?

To me, that looks like you are calling init on super. Best Josh Sent from my iPhone On Sep 26, 2017, at 17:03, William Shipley via swift-evolution > wrote: In cases like this: override func loadView() { super.loadView()

[swift-evolution] Idea: using 'super()' as syntactic sugar for 'super.overriddenmethod(...)'?

In cases like this: override func loadView() { super.loadView() view.addSubview(segmentedControl) segmentedControl.translatesAutoresizingMaskIntoConstraints = false segmentedControl.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true }

Re: [swift-evolution] Re-pitch: remove(where:)

Er… sorry, by “returns results” I mean, return the removed items. Thanks, Jon > On Sep 26, 2017, at 4:59 PM, Jonathan Hull wrote: > > The main issue here is that the proposal is missing the variant which returns > the elements that are removed… and that throws out a lot of

Re: [swift-evolution] Re-pitch: remove(where:)

The main issue here is that the proposal is missing the variant which returns the elements that are removed… and that throws out a lot of very useful use cases. > 1. Is it right to assert that with a “removing” operation, the closure should > return `true` for removal? Yes > 2. Is it likely

Re: [swift-evolution] Re-pitch: remove(where:)

I think it is worth considering a version which both removes items in place, and also returns the removed items, so as to split the collection by a predicate. Nevin ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Re-pitch: remove(where:)

formFilter reads really weirdly... the use of filter in `filter` is not as a noun, but as a verb — compare to e.g., formRemainder. Calling formFilter won’t create a filter, it will “do” a filter. Perhaps formByFiltering? > On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Question about async await

Pierre responded to the rest of your comments, but I wanted to briefly touch on this: > On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution > wrote: > > In C#, the model is far simple as there is not concept of a single dispatch > queue that can execute

Re: [swift-evolution] Re-pitch: remove(where:)

On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > And here are my answers, in a separate email to maintain a shred of > separation between objectivity and subjectivity :) > > > On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution < >

Re: [swift-evolution] [Proposal] Random Unification

On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier wrote: > > > Le 26 sept. 2017 à 07:31, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit : > > > * The distinction to be made here is CSPRNGs versus non-cryptographically > secure PRNGs, where CSPRNG :

Re: [swift-evolution] Re-pitch: remove(where:)

And here are my answers, in a separate email to maintain a shred of separation between objectivity and subjectivity :) > On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution > wrote: > > 1. Is it right to assert that with a “removing” operation, the closure

[swift-evolution] Re-pitch: remove(where:)

Hi everyone, Reviving a pitch for a feature that didn’t make it into Swift 4. This was discussed in the core team recently, and feedback was wanted regarding the naming of the method and the polarity of the where closure. Here’s the proposal:

Re: [swift-evolution] Question about async await

> Le 26 sept. 2017 à 22:38, Pierre Habouzit a écrit : > >> On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution >> > wrote: >> >>> Le 26 sept. 2017 à 00:13, Adam Kemp >>

Re: [swift-evolution] Question about async await

> On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution > wrote: > >> Le 26 sept. 2017 à 00:13, Adam Kemp a écrit : >> >>> On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution >>> wrote: >>> Le

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Sent from my iPhone > On Sep 25, 2017, at 22:16, Jonathan Hull via swift-evolution > wrote: > > As he says, it is an in-place equivalent of filter, so the use-cases would be > similar. I could see this being extremely useful. Off the top of my head: > >

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 26, 2017, at 2:59 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Sep 26, 2017 at 00:15 Jonathan Hull > wrote: > As he says, it is an in-place equivalent of filter, so the use-cases would be > similar. I

Re: [swift-evolution] Question about async await

> Le 26 sept. 2017 à 00:13, Adam Kemp a écrit : > > >> On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution >> wrote: >> >>> Le 25 sept. 2017 à 21:42, John McCall via swift-evolution >>> a écrit : >>> >>>

Re: [swift-evolution] [Proposal] Random Unification

> Le 26 sept. 2017 à 07:31, Xiaodi Wu via swift-evolution > a écrit : > > * The distinction to be made here is CSPRNGs versus non-cryptographically > secure PRNGs, where CSPRNG : PRNG. “Reproducible” is not the right word. > Based on my understanding, some CSPRNGs

Re: [swift-evolution] [Proposal] Random Unification

Felix and Jonathan make some good points. Some general comments: * I think, in general, this area needs a detailed review by those who are expert in the domain; especially if we are to assert that the design is cryptographically secure, we need to ensure that it is actually so. In other words,

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Considering some of the suggestions which have come up here I'm glad to say that I have been able to achieve the in-place filter and remove(where:) functionalities by using existing APIs. Alwyn On Tuesday, 26 September 2017, 4:47:48 PM IST, Karl Wagner wrote:

Re: [swift-evolution] [Proposal] Random Unification

Instead of “UnsafeRandomSource”, I would call it “ReproducibleRandomSource”. I have also found that you often need to be able to “rewind” a reproducible random source for graphics applications: protocol ReproducibleRandomSource : RandomSource { init(seed: UInt64)

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Yeah, IMO it’s fair to add this function. I also think we should have a way of removing elements at multiple indexes (e.g. from a generic sequence of indexes). That’s something that naïve programmers are more likely to get wrong. - Karl > On 26. Sep 2017, at 06:27, Félix Cloutier via

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

That is very nice. Unless someone can show how this can be easily achieved in an ergonomic way with today’s APIs, I am on board with remove(where:). On Tue, Sep 26, 2017 at 05:28 Jonathan Hull wrote: > Alwyn just pointed out another use-case as well. > > If there is either a

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Alwyn just pointed out another use-case as well. If there is either a @discardableResult or two variants (one which returns a result) where the method returns the items being removed (which is to be expected of a method named “remove”), then it becomes useful in ways which filter alone is not.

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 26, 2017, at 2:37 AM, Alwyn Concessao wrote: > > @Jonathan Hull - You've mentioned about splitting a list using a filter > which returns the filtered list and the remainder.Is it similar to having a > filter function which does the filtering on the original

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

On Tue, Sep 26, 2017 at 00:15 Jonathan Hull wrote: > As he says, it is an in-place equivalent of filter, so the use-cases would > be similar. I could see this being extremely useful. Off the top of my > head: > > views.remove(where: {$0.isHidden}) //Remove all views which are

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

First of all thanks to you all for the suggestions/thoughts on this idea. @Jonathan Hull - You've mentioned  about splitting a list using a filter which returns the filtered list and the remainder.Is it similar to having a filter function which does the filtering on the original collection and

Re: [swift-evolution] [Proposal] Random Unification

I'm okay with "unqualified" random being crypto-secure and qualifying non-crypto-secure generators as inferior, but I think that Unsafe is not the qualifier we are looking for. Everywhere else, Unsafe implies that misuse will cause unpredictable results/crashes, which is a different class of

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

You wouldn’t normally use Reactive Streams directly, think of them as the Babel Fish (hitch hikers) of Streams/actors. If Swift actors talked Reactive Stream and so did some other library, Akka, RxSwift, etc., then the two could talk to each other. Which would be a big advantage on large projects

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

Nothing to stop you having Observables linked to a Reactive Stream library, the RxJava 2 library has Observables and is built on top of Reactive Streams. On Mon, 25 Sep 2017 at 5:15 am, Marc Schlichte via swift-evolution < swift-evolution@swift.org> wrote: > I hope we come up with some genuine

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

Comments in-line below. On Sun, 24 Sep 2017 at 12:36 pm, Matt Gallagher via swift-evolution < swift-evolution@swift.org> wrote: > Some thoughts as a programmer who has written an atypical reactive > programming library... > > You're providing protocols that strongly imply ReactiveX semantics.

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Same as `filter`, but in-place. We thought that `sorted` deserved an in-place version; that +(Array, Array) deserved an in-place version (append(contentsOf:)); there are parallels to be made between `dropFirst` and `removeFirst`; we have index and formIndex. There's a ton more, Swift loves to

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

Not quite understanding your concern, perhaps you could elaborate. In particular: 1. The names I proposed were on(next:) and on(error:) so there is no confusion since next and error are still part of the name. I just moved them inside the brackets like commonly done in Swift. 2. Neither

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

I stuck with the standard names that other languages use. In Java they enclosed the standard protocol/interface names Process, Publisher, Subscriber, along with a useful constant inside a namespace Flow, so you say Flow.Publisher for example. The same could be done for Swift, it is a matter for