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

[Félix Cloutier via swift-evolution]

> 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 sequence, but when you use it as a CSPRNG, you typically feed 
> entropy back into it at nondeterministic points to ensure that even if you 
> started with a bad seed, you'll eventually get to an alright state. Unless 
> you keep track of when entropy was mixed in and what the values were, you'll 
> never get a reproducible CSPRNG.
> 
> We would give developers a false sense of security if we provided them with 
> CSPRNG-grade algorithms that we called CSPRNGs and that they could seed 
> themselves. Just because it says "crypto-secure" in the name doesn't mean 
> that it'll be crypto-secure if it's seeded with time(). Therefore, 
> "reproducible" vs "non-reproducible" looks like a good distinction to me.
> 
> I disagree here, in two respects:
> 
> First, whether or not a particular PRNG is cryptographically secure is an 
> intrinsic property of the algorithm; whether it's "reproducible" or not is 
> determined by the published API. In other words, the distinction between 
> CSPRNG vs. non-CSPRNG is important to document because it's semantics that 
> cannot be deduced by the user otherwise, and it is an important one for 
> writing secure code because it tells you whether an attacker can predict 
> future outputs based only on observing past outputs. "Reproducible" in the 
> sense of seedable or not is trivially noted by inspection of the published 
> API, and it is rather immaterial to writing secure code.

Cryptographically secure is not a property that I'm comfortable applying to an 
algorithm. You cannot say that you've made a cryptographically secure thing 
just because you've used all the right algorithms: you also have to use them 
right, and one of the most critical components of a cryptographically secure 
PRNG is its seed. It is a *feature* of a lot of modern CSPRNGs that you can't 
seed them:

You cannot seed or add entropy to std::random_device
You cannot seed or add entropy to CryptGenRandom
You can only add entropy to /dev/(u)random
You can only add entropy to BSD's arc4random

Just because we can expose a seed interface doesn't mean we should, and in this 
case I believe that it would go against the prime objective of providing secure 
random numbers.

> If your attacker can observe your seeding once, chances are that they can 
> observe your reseeding too; then, they can use their own implementation of 
> the PRNG (whether CSPRNG or non-CSPRNG) and reproduce your pseudorandom 
> sequence whether or not Swift exposes any particular API.

On Linux, the random devices are initially seeded with machine-specific but 
rather invariant data that makes /dev/urandom spit out predictable numbers. It 
is considered "seeded" after a root process writes POOL_SIZE bytes to it. On 
most implementations, this initial seed is stored on disk: when the computer 
shuts down, it reads POOL_SIZE bytes from /dev/urandom and saves it in a file, 
and the contents of that file is loaded back into /dev/urandom when the 
computer starts. A scenario where someone can read that file is certainly not 
less likely than a scenario where /dev/urandom was deleted. That doesn't mean 
that they have kernel code execution or that they can pry into your process, 
but they have a good shot at guessing your seed and subsequent RNG results if 
no stirring happens.

> Secondly, I see no reason to justify the notion that, simply because a PRNG 
> is cryptographically secure, we ought to hide the seeding initializer 
> (because one has to exist internally anyway) from the public. Obviously, one 
> use case for a deterministic PRNG is to get reproducible sequences of 
> random-appearing values; this can be useful whether the underlying algorithm 
> is cryptographically secure or not. There are innumerably many ways to use 
> data generated from a CSPRNG in non-cryptographically secure ways and 
> omitting or including a public seeding initializer does not change that; in 
> other words, using a deterministic seed for a CSPRNG would be a bad idea in 
> certain applications, but it's a deliberate act, and someone who would 
> mistakenly do that is clearly incapable of *using* the output from the PRNG 
> in a secure way either; put a third way, you would be hard pressed to find a 
> situation where it's true that "if only Swift had not made the seeding 
> initializer public, this author would have written secure code, but instead 
> the only security hole that existed in the code was caused by the 
> availability of a public seeding initializer mistakenly used." The point of 
> having both explicitly instantiable PRNGs and a layer of simpler APIs like 
> "Int.random()" is so that the less experienced user can get the "right thing" 
> by default, and the 

Re: [swift-evolution] Question about async await

[Pierre Habouzit via swift-evolution]

-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 
>>> > 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 25 sept. 2017 à 21:42, John McCall via swift-evolution 
>> > a écrit :
>> 
>> This doesn't have to be the case, actually.  The intrinsics as Chris 
>> described them wouldn't be sufficient, but you could require a "current 
>> queue" to be provided when kicking off an async function from scratch, 
>> as well as any other "async-local" context information you wanted (e.g. 
>> QoS and the other things that Dispatch tracks with attributes/flags that 
>> are generally supposed to persist across an entire async operation).
>> 
> 
> My response was about the ‘implicitly’ part. I hope we will get a rich 
> API that let us specify return queue, QoS and more, but how do you plan 
> to fulfill the « current queue » requirement implicitly ?
 
 My earlier response to this thread both linked to a previous thread about 
 this and explained how C# does it. It will require some library support, 
 but it can be done, and IMO should be done. As I’ve stressed repeatedly, 
 async/await without this behavior will be very difficult to use correctly. 
 I really hope we don’t settle for that.
>>> 
>>> In C#, the model is far simple as there is not concept of a single dispatch 
>>> queue that can execute work on any thread. You can easily use TLS to store 
>>> a default context. Each UI thread can have a context that dispatch 
>>> completion on the message queue, but AFAIK,
>> 
>> 
>>> there is not DispatchQueue Local Storage yet.
>> 
>> There is, see dispatch_queue*_specific()
>> 
>>> Even something as simple as getting the current queue is not reliable (see 
>>> dispatch_get_current_queue man page for details).
>> 
>> This is a sharp construct for clients, but not for the runtime / compiler 
>> that can be taught how not to fall in the traps of this API.
>> 
>> Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but 
>> has two major issues: nesting & refcounting.
>> 
>> 
>> Nesting
>> 
>> Nesting refers to the fact that when you call code that takes a queue and a 
>> callback, you may observe *another* queue:
>> 
>> run_something_and_call_me_back(arg1, arg2, on_queue, ^{
>> assert(dispatch_get_current_queue() == on_queue); // may crash
>> ... my stuff ...
>> });
>> 
>> The reason is that run_something_and_call_me_back() may create a queue that 
>> targets `on_queue` and then this private queue is what is returned which is 
>> both unexpected and exposing internals of the implementation of 
>> run_something_and_call_me_back() which is all wrong.
>> 
>> A corollary is that people attempting to implement recursive locking (which 
>> is a bad idea in general anyway) with dispatch_get_current_queue() will fail 
>> miserably.
>> 
>> Refcounting
>> 
>> Because dispatch has a notion of internal refcount, in ARC world, this will 
>> crash most of the time:
>> 
>> dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
>> __strong dispatch_queue cq = dispatch_get_current_queue(); // will 
>> usually crash with a resurrection error
>> });
>> 
>> 
>> These two edges is why we deprecated this interface for humans.
>> 
>> 1) A compiler though is not affected by the first issue because the context 
>> it would capture would have to not be programatically accessible to clients
>> 2) The Swift runtime can know to take "internal" refcounts when capturing 
>> this hidden pointer and is not affected by the second problem either.
>> 
>> 
>> tl;dr: what is badly defined is allowing clients to get a pointer to the 
>> current queue with a real +1, but that is WAY stronger than what the 
>> language runtime needs.
>> 
>> 
>>> That’s why I’m saying it will be difficult to define a reasonable default 
>>> context that can be used implicitly.
>> 
>> This is just not true. This is both easy and reasonable.
>> 
> 
> I’m glade to be wrong about that point ;-)
> One issue I still see is what should be the default when running on a bare 
> pthread outside of any queue context. Or is there a queue associated with any 
> thread ?

My thinking is that we need to have a notion of "current place to run swift 
bullshi^Wclosures".
It could be the current queue if there's one, or the current CFRunLoop (if 
there's one already made)
It could be the current "libfoobar 

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

[Robert Bennett via swift-evolution]

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 to e.g., formRemainder. Calling formFilter 
>> won’t create a filter, it will “do” a filter. Perhaps formByFiltering?
> 
> That's interesting. I worry it might be too clever by half, though.
> 
> The prototypical "form" method is "formUnion"; it's so named because the term 
> "union" is used in math as both noun and verb ("a union b"; "the union of a 
> and b") and is a term of art that doesn't lend itself to the noun/verb rule 
> in Swift. Here, "filter" is a term of art (otherwise, it'd be called 
> "filtered"); now that "filter" is the non-mutating function (i.e., what 
> should otherwise be a noun), there's no way to maintain the noun/verb rule in 
> Swift. Therefore, without overthinking it, "formFilter".
> 
> Note that it's not "formUnion(with:)", just "formUnion(_:)". As is the case 
> with "formUnion", no particular attempt is made here to turn this method name 
> into an English phrase. The phrase "by filtering" very strongly suggests 
> true-to-remove; that's the only way the term "filtering" is used in English. 
> Here, we mean true-to-keep, and there's no way to express that with the 
> English word "filter" between the receiver and the predicate with any sort of 
> conjugation of the word or concise combination of helper words. The nearest 
> good-English name might be something like 
> "formFilteredResultKeeping(where:)", which is clearly awful for other reasons.
> 
>>> On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution 
  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 
 >  wrote:
 >
 > 1. Is it right to assert that with a “removing” operation, the closure 
 > should return `true` for removal?
 
 Yes. If the closure returned false for removal a different, less readable, 
 name would be needed for the method.
>>> 
>>> Agree, yes.
>>> 
 > 2. Is it likely that users will want to switch from out-of- to in-place, 
 > and if so, will having to flip the closure cause confusion/bugs?
 
 I don’t think so. While the argument for an in-place remove is partly that 
 it’s more efficient than x = x.filter (in addition to 
 reability/discoverability benefits), I think that once both an in- and 
 out-of-place version are available, users will reach immediately for the 
 one they want. The scenario where you were filtering, and then you realize 
 you could do it in-place more efficiently, doesn’t seem to me like it will 
 come up in day-to-day use.
>>> 
>>> Unsure. Maybe and maybe, but I think the confusion/bugs would be limited if 
>>> the full matrix of four operations exist.
>>>  
 > 3. Should we “complete” the matrix of 4 operations, or is it fine for it 
 > to have gaps?
 
 I think filter(_:) and remove(where:) are sufficient. I don’t think we 
 need to complete the set.
>>> 
>>> Based on question (2), I would argue that the answer is yes.
>>> 
 > 4. If you are for completing, what should X and Y be called?
 >
 
 One of the reasons I _don’t_ think we should complete the set is that 
 formFilter(_:) will take us into serious jumped-the-shark territory, 
 naming-wise.
 
 I think there’s an argument for never having had filter, and always having 
 had remove/removed (or possibly select/selected), but don’t think this is 
 important enough to clear the bar for a rename of this magnitude.
>>> 
>>> IMO, they should be called removing(where:) [removed(where:) reads weirdly 
>>> in conjunction with the preceding receiver] and formFilter(_:). Hundreds of 
>>> messages finally settled on "form" as the in-place verb of choice where the 
>>> noun can't ordinarily be verbed. No point in being shy about it now: that's 
>>> the Swift way, wear it proudly.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 formByFiltering?
>

That's interesting. I worry it might be too clever by half, though.

The prototypical "form" method is "formUnion"; it's so named because the
term "union" is used in math as both noun and verb ("a union b"; "the union
of a and b") and is a term of art that doesn't lend itself to the noun/verb
rule in Swift. Here, "filter" is a term of art (otherwise, it'd be called
"filtered"); now that "filter" is the non-mutating function (i.e., what
should otherwise be a noun), there's no way to maintain the noun/verb rule
in Swift. Therefore, without overthinking it, "formFilter".

Note that it's not "formUnion(with:)", just "formUnion(_:)". As is the case
with "formUnion", no particular attempt is made here to turn this method
name into an English phrase. The phrase "by filtering" very strongly
suggests true-to-remove; that's the only way the term "filtering" is used
in English. Here, we mean true-to-keep, and there's no way to express that
with the English word "filter" between the receiver and the predicate with
any sort of conjugation of the word or concise combination of helper words.
The nearest good-English name might be something like
"formFilteredResultKeeping(where:)", which is clearly awful for other
reasons.

On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 <
>> swift-evolution@swift.org> wrote:
>> >
>> > 1. Is it right to assert that with a “removing” operation, the closure
>> should return `true` for removal?
>>
>> Yes. If the closure returned false for removal a different, less
>> readable, name would be needed for the method.
>>
>
> Agree, yes.
>
> > 2. Is it likely that users will want to switch from out-of- to in-place,
>> and if so, will having to flip the closure cause confusion/bugs?
>>
>> I don’t think so. While the argument for an in-place remove is partly
>> that it’s more efficient than x = x.filter (in addition to
>> reability/discoverability benefits), I think that once both an in- and
>> out-of-place version are available, users will reach immediately for the
>> one they want. The scenario where you were filtering, and then you realize
>> you could do it in-place more efficiently, doesn’t seem to me like it will
>> come up in day-to-day use.
>>
>
> Unsure. Maybe and maybe, but I think the confusion/bugs would be limited
> if the full matrix of four operations exist.
>
>
>> > 3. Should we “complete” the matrix of 4 operations, or is it fine for
>> it to have gaps?
>>
>> I think filter(_:) and remove(where:) are sufficient. I don’t think we
>> need to complete the set.
>
>
> Based on question (2), I would argue that the answer is yes.
>
> > 4. If you are for completing, what should X and Y be called?
>> >
>>
>> One of the reasons I _don’t_ think we should complete the set is that
>> formFilter(_:) will take us into serious jumped-the-shark territory,
>> naming-wise.
>>
>> I think there’s an argument for never having had filter, and always
>> having had remove/removed (or possibly select/selected), but don’t think
>> this is important enough to clear the bar for a rename of this magnitude.
>
>
> IMO, they should be called removing(where:) [removed(where:) reads weirdly
> in conjunction with the preceding receiver] and formFilter(_:). Hundreds of
> messages finally settled on "form" as the in-place verb of choice where the
> noun can't ordinarily be verbed. No point in being shy about it now: that's
> the Swift way, wear it proudly.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Susan Cheng via swift-evolution]

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, and I’ve been working on a design 
> that tries to utilize everybody’s ideas. The link to what I have so far is 
> here: https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1. Please 
> keep in mind this is just a design, no actual implementation as I would most 
> likely need assistance in doing. The default source for randomness will use 
> the OS’s unseeded CSPRNG. This current setup exposes developers to an API 
> that lets them create their own RandomSources on the fly. I want to make the 
> distinction that any existing or new sources of randomness that conform to 
> UnsafeRandomSource are to be considered non cryptographically secure.
> 
> I would love to get this discussion flowing again, and I would love input on 
> the design. A few things I came across with this design is that some may want 
> to use ranges as an argument for the numeric types, RandomAccessCollection 
> returning an optional when getting a random, and how to incorporate an API 
> that allows distributions. I wanted to get input on how you feel about each 
> of these topics as I’m indifferent about them all. I’m in no way saying this 
> is the design we should go for, but I’m simply providing something I think we 
> should build on or talk about.
> 
> - Alejandro
> 
>> On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution 
>> , wrote:
>> Hello swift evolution, I would like to propose a unified approach to 
>> `random()` in Swift. I have a simple implementation here 
>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This 
>> implementation is a simple wrapper over existing random functions so 
>> existing code bases will not be affected. Also, this approach introduces a 
>> new random feature for Linux users that give them access to upper bounds, as 
>> well as a lower bound for both Glibc and Darwin users. This change would be 
>> implemented within Foundation.
>> 
>> I believe this simple change could have a very positive impact on new 
>> developers learning Swift and experienced developers being able to write 
>> single random declarations.
>> 
>> I’d like to hear about your ideas on this proposal, or any implementation 
>> changes if need be.
>> 
>> - Alejando
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Drayer via swift-evolution]

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 implicitly annotating one (CS)PRNG as the 
de-facto RNG for Swift on all platforms, as well as remove the requirement for 
providing a `shared` singleton on every (CS)PRNG.

I’m imagining something like this (names taken from, or inspired by, Félix’s 
design for consistency within this discussion, I’m not strongly attached to any 
of them):

```swift
protocol StandardRandomSource {
static var generator: RandomSource { get }
}

extension StandardRandomSource {
static var generator: RandomSource {
#if os(Linux)
// /dev/random chosen naively
return DeviceRandom.shared
#elseif os(macOS) || os(iOS) || os(watchOS) || os(tvOS)
// SecCopyRandomBytes-based, also chosen naively
return SecRandomSource()
#else
fatalError("Standard source of randomness not provided on 
current platform")
#endif
}
}
```

and this new protocol could be used like this (largely copied from Félix’s 
design):

```swift
extension Randomizable {
public static var random: Self {
return random(using: StandardRandomSource.generator)
}
}

extension FixedWidthInteger: {
public static func random(using source: RandomSource = 
StandardRandomSource.generator) -> Self {
return (0 ..< Self.max).random(using: source)
}
}
```

On a more meta level, introducing this protocol lets us (Swift Evolution) kick 
the question of “What (CS)PRNG gets implemented for a given OS as the default 
provider?” further down the road instead of potentially blocking discussion for 
a long time.

Another possible upside that I can think of is: We could let per-platform 
implementations of this protocol could happen outside of the Swift Evolution 
process. Hopefully this means it would be easier to amend or fix in the future, 
as new platforms are added and new best practices arise.

A downside to this idea is that we’d be adding a protocol to the stdlib that 
isn’t intended for people to implement, although there’s no possible harm if 
anyone does so.

One other idea I also explored, but ultimately decided against was having 
per-platform `typealias`es instead of a protocol with a default implementation. 
Without a way to get an instance of a random number generator, I fell back to 
requiring `var shared: Self` to stay in `RandomSource`, which didn’t seem as 
necessary.

-z

> On Sep 25, 2017, at 9:57 PM, Alejandro Alonso via swift-evolution 
>  wrote:
> 
> Hello evolution,
> 
> I am very thankful for all the feedback, and I’ve been working on a design 
> that tries to utilize everybody’s ideas. The link to what I have so far is 
> here: https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1. Please 
> keep in mind this is just a design, no actual implementation as I would most 
> likely need assistance in doing. The default source for randomness will use 
> the OS’s unseeded CSPRNG. This current setup exposes developers to an API 
> that lets them create  their own RandomSources on the fly. I want to make the 
> distinction that any existing or new sources of randomness that conform to 
> UnsafeRandomSource are to be considered non cryptographically secure.
> 
> I would love to get this discussion flowing again, and I would love input on 
> the design. A few things I came across with this design is that some may want 
> to use ranges as an argument for the numeric types, RandomAccessCollection 
> returning an optional when getting a random, and how to incorporate an API 
> that allows distributions. I wanted to get input on how you feel about each 
> of these topics as I’m indifferent about them all. I’m in no way saying this 
> is the design we should go for, but I’m simply providing something I think we 
> should build on or talk about.
> 
> - Alejandro
> 
>> On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution 
>> , wrote:
>> Hello swift evolution, I would like to propose a unified approach to 
>> `random()` in Swift. I have a simple implementation here 
>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This 
>> implementation is a simple wrapper over existing random functions so 
>> existing code bases will not be affected. Also, this approach introduces a 
>> new random feature for Linux users that give them access to upper bounds, as 
>> well as a lower bound for both Glibc and Darwin users. This change would be 
>> implemented within Foundation.
>> 
>> I believe this simple change could have a very positive impact on new 
>> developers learning Swift and experienced developers being able to write 
>> single random 

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

[Josh Parmenter via swift-evolution]

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()
view.addSubview(segmentedControl)
segmentedControl.translatesAutoresizingMaskIntoConstraints = false
segmentedControl.centerXAnchor.constraint(equalTo: 
view.centerXAnchor).isActive = true
}

or

override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
if let destinationController = segue.destinationController as? 
ScaleViewController {
scaleViewController = destinationController
destinationController.scalable = self // weak back-link
}
super.prepare(for: segue, sender: sender)
}

We obviously need the ability to manually place the call to 'super' in our 
overridden methods, so we can't just have the compiler always automatically 
call super (like it does with dealloc).

But only occasionally do we need to pass in different parameters to the 
superclass method than were passed into us, and it'd be nice to ? not have to 
do all the extra typing / reading in the common case, ? makes it clear at a 
glance we're calling the _same_ method on our superclass, not accidentally 
calling a different one, and ? make it especially noticeable when we ARE 
changing the parameters around to our call to super by having that be the only 
version where you need to specify them.

So, for instance, the above two methods would turn into:

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

or

override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
if let destinationController = segue.destinationController as? 
ScaleViewController {
scaleViewController = destinationController
destinationController.scalable = self // weak back-link
}
super()
}

But this contrived example would stay the same:

override public func mouseDown(with event: NSEvent) {
let someOtherEvent = ...
super.mouseDown(with: someOtherEvent)
}

Note that I just made up a contrived example here because I couldn't find a 
single real-world case in my 33,098 lines of Swift code where I call 
super.blah(...) with different parameters than the ones that were passed in, 
which I think also points to why this syntactic sugar is sweet and low-cal. 
(The only time I saw super being called with different parameters was in init() 
methods, where I was calling a different initializer.)

-

Another version would be to use a new word instead of "super()", which doesn't 
overload the noun-ish-ness of 'super':

overridden()
or
superfunc()


It's possible that the empty parenthesis in "super()" would confuse readers 
into thinking some other version of their function is being called (that has no 
parameters), so it's worth considering if something like "overridden" by itself 
(no ()) would be better. I think if this is a worry I'd prefer to use three 
dots to indicate more stuff is going on here, to match with our documentation:

super(...)
or
overridden(...)

An orthogonal idea is for the contrived example would be to allow new 
parameters to be passed in directly without typing the function name again:

super(with: someOtherEvent)
or
overridden(with: someOtherEvent)


-Wil


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[William Shipley via swift-evolution]

In cases like this:

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

or

override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
if let destinationController = segue.destinationController as? 
ScaleViewController {
scaleViewController = destinationController
destinationController.scalable = self // weak back-link
}
super.prepare(for: segue, sender: sender)
}

We obviously need the ability to manually place the call to ‘super’ in our 
overridden methods, so we can’t just have the compiler always automatically 
call super (like it does with dealloc).

But only occasionally do we need to pass in different parameters to the 
superclass method than were passed into us, and it’d be nice to ⑴ not have to 
do all the extra typing / reading in the common case, ⑵ makes it clear at a 
glance we’re calling the _same_ method on our superclass, not accidentally 
calling a different one, and ⑶ make it especially noticeable when we ARE 
changing the parameters around to our call to super by having that be the only 
version where you need to specify them.

So, for instance, the above two methods would turn into:

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

or

override open func prepare(for segue: NSStoryboardSegue, sender: Any?) {
if let destinationController = segue.destinationController as? 
ScaleViewController {
scaleViewController = destinationController
destinationController.scalable = self // weak back-link
}
super()
}

But this contrived example would stay the same:

override public func mouseDown(with event: NSEvent) {
let someOtherEvent = …
super.mouseDown(with: someOtherEvent)
}

Note that I just made up a contrived example here because I couldn’t find a 
single real-world case in my 33,098 lines of Swift code where I call 
super.blah(…) with different parameters than the ones that were passed in, 
which I think also points to why this syntactic sugar is sweet and low-cal. 
(The only time I saw super being called with different parameters was in init() 
methods, where I was calling a different initializer.)

—

Another version would be to use a new word instead of “super()”, which doesn’t 
overload the noun-ish-ness of ‘super’:

overridden()
or
superfunc()


It’s possible that the empty parenthesis in “super()” would confuse readers 
into thinking some other version of their function is being called (that has no 
parameters), so it’s worth considering if something like “overridden” by itself 
(no ()) would be better. I think if this is a worry I’d prefer to use three 
dots to indicate more stuff is going on here, to match with our documentation:

super(...)
or
overridden(...)

An orthogonal idea is for the contrived example would be to allow new 
parameters to be passed in directly without typing the function name again:

super(with: someOtherEvent)
or
overridden(with: someOtherEvent)


-Wil


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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 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 that users will want to switch from out-of- to in-place, and 
>> if so, will having to flip the closure cause confusion/bugs?
> They always have the option of just inverting the closure.  I doubt people 
> will change the function being used unless they are doing a larger refactor 
> (or need the removed results).
> 
>> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
>> have gaps?
> I am on the fence.  I don’t think gaps will cause an issue, but I could see 
> the usefulness of having more options (but are they worth the upkeep?).
> 
>> 4. If you are for completing, what should X and Y be called?
> removing(where:) and formFilter()  (though I have always been a fan of 
> filter/filtered)
> 
> 
> As I mentioned above, I think that either returning @discardableResults or 
> having a variant which returns the results is very important.  Look at the 
> other thread on this topic from this morning for a discussion of why.
> 
> Thanks,
> Jon
> 
> 
>> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> 
>> 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:
>> 
>> https://github.com/airspeedswift/swift-evolution/blob/0f4a24d6ded2ab7cb39c1a68e0f92705a7615d73/proposals/-RemoveWhere.md
>> 
>> To keep things simple, this version removes the Equatable version. That 
>> could be added as a separate proposal.
>> 
>> 
>> The issue to resolve is: should the closure have the same polarity as 
>> filter, and if not, should filter also have an in-place equivalent?
>> (wait, don’t reply yet, read the rest of the email first :)
>> 
>> From the original proposal:
>> 
>>> `remove(where:)` takes a closure with `true` for elements to remove. 
>>> `filter` takes a closure with `true` for elements to keep. In both cases, 
>>> `true` is the "active" case, so likely to be what the user wants without 
>>> having to apply a negation. The naming of `filter` is unfortunately 
>>> ambiguous as to whether it’s a removing or keeping operation, but 
>>> re-considering that is outside the scope of this proposal.
>> 
>> 
>> Assuming you accept the premise that a closure returning `true` to `remove` 
>> is the “right way around” for the argument to an in-place removal operation, 
>> this means that we have a situation where if you want to flip from in-place 
>> to out-of-place removal, you have to reverse the closure.
>> 
>> Alternatively, we could duplicate the functionality, and have both filter 
>> and remove operations have in- and out-of-place variants, completing this 
>> 2x2 matrix:
>> 
>> out-of-place, true to keep:  filter(_:)
>> in-place, true to remove:remove(where:)
>> out-of-place, true to remove:X?
>> in-place, true to keep:  Y?
>> 
>> The names for X that fall easily out of the naming guidelines are 
>> removed(where:) or removing(where:)
>> 
>> Y is trickier. Normally, the out-of-place would be a variant (like the past 
>> participle) of the mutating operation, but with filter the out-of-place 
>> method is already named,* so options are limited. formFilter(_:) is one 
>> suggestion.
>> 
>> 
>> To help guide feedback on this, here are 4 questions to answer:
>> 
>> 1. Is it right to assert that with a “removing” operation, the closure 
>> should return `true` for removal?
>> 2. Is it likely that users will want to switch from out-of- to in-place, and 
>> if so, will having to flip the closure cause confusion/bugs?
>> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
>> have gaps?
>> 4. If you are for completing, what should X and Y be called?
>> 
>> Any answers, or further thoughts on any of the above, appreciated.
>> 
>> Ben
>> 
>> 
>> 
>> * while you could argue that this can be resolved by renaming filter, 
>> renames like this have a very high bar to clear. Also, filter is a term of 
>> art, hence its previous exemption from the naming guidelines.
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jonathan Hull via swift-evolution]

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 that users will want to switch from out-of- to in-place, and 
> if so, will having to flip the closure cause confusion/bugs?
They always have the option of just inverting the closure.  I doubt people will 
change the function being used unless they are doing a larger refactor (or need 
the removed results).

> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
> have gaps?
I am on the fence.  I don’t think gaps will cause an issue, but I could see the 
usefulness of having more options (but are they worth the upkeep?).

> 4. If you are for completing, what should X and Y be called?
removing(where:) and formFilter()  (though I have always been a fan of 
filter/filtered)


As I mentioned above, I think that either returning @discardableResults or 
having a variant which returns the results is very important.  Look at the 
other thread on this topic from this morning for a discussion of why.

Thanks,
Jon


> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
> 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:
> 
> https://github.com/airspeedswift/swift-evolution/blob/0f4a24d6ded2ab7cb39c1a68e0f92705a7615d73/proposals/-RemoveWhere.md
> 
> To keep things simple, this version removes the Equatable version. That could 
> be added as a separate proposal.
> 
> 
> The issue to resolve is: should the closure have the same polarity as filter, 
> and if not, should filter also have an in-place equivalent?
> (wait, don’t reply yet, read the rest of the email first :)
> 
> From the original proposal:
> 
>> `remove(where:)` takes a closure with `true` for elements to remove. 
>> `filter` takes a closure with `true` for elements to keep. In both cases, 
>> `true` is the "active" case, so likely to be what the user wants without 
>> having to apply a negation. The naming of `filter` is unfortunately 
>> ambiguous as to whether it’s a removing or keeping operation, but 
>> re-considering that is outside the scope of this proposal.
> 
> 
> Assuming you accept the premise that a closure returning `true` to `remove` 
> is the “right way around” for the argument to an in-place removal operation, 
> this means that we have a situation where if you want to flip from in-place 
> to out-of-place removal, you have to reverse the closure.
> 
> Alternatively, we could duplicate the functionality, and have both filter and 
> remove operations have in- and out-of-place variants, completing this 2x2 
> matrix:
> 
> out-of-place, true to keep:   filter(_:)
> in-place, true to remove: remove(where:)
> out-of-place, true to remove: X?
> in-place, true to keep:   Y?
> 
> The names for X that fall easily out of the naming guidelines are 
> removed(where:) or removing(where:)
> 
> Y is trickier. Normally, the out-of-place would be a variant (like the past 
> participle) of the mutating operation, but with filter the out-of-place 
> method is already named,* so options are limited. formFilter(_:) is one 
> suggestion.
> 
> 
> To help guide feedback on this, here are 4 questions to answer:
> 
> 1. Is it right to assert that with a “removing” operation, the closure should 
> return `true` for removal?
> 2. Is it likely that users will want to switch from out-of- to in-place, and 
> if so, will having to flip the closure cause confusion/bugs?
> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
> have gaps?
> 4. If you are for completing, what should X and Y be called?
> 
> Any answers, or further thoughts on any of the above, appreciated.
> 
> Ben
> 
> 
> 
> * while you could argue that this can be resolved by renaming filter, renames 
> like this have a very high bar to clear. Also, filter is a term of art, hence 
> its previous exemption from the naming guidelines.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nevin Brackett-Rozinsky via swift-evolution]

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
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Bennett via swift-evolution]

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 
>  wrote:
> 
>> On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution 
>>  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 
>> >  wrote:
>> >
>> > 1. Is it right to assert that with a “removing” operation, the closure 
>> > should return `true` for removal?
>> 
>> Yes. If the closure returned false for removal a different, less readable, 
>> name would be needed for the method.
> 
> Agree, yes.
> 
>> > 2. Is it likely that users will want to switch from out-of- to in-place, 
>> > and if so, will having to flip the closure cause confusion/bugs?
>> 
>> I don’t think so. While the argument for an in-place remove is partly that 
>> it’s more efficient than x = x.filter (in addition to 
>> reability/discoverability benefits), I think that once both an in- and 
>> out-of-place version are available, users will reach immediately for the one 
>> they want. The scenario where you were filtering, and then you realize you 
>> could do it in-place more efficiently, doesn’t seem to me like it will come 
>> up in day-to-day use.
> 
> Unsure. Maybe and maybe, but I think the confusion/bugs would be limited if 
> the full matrix of four operations exist.
>  
>> > 3. Should we “complete” the matrix of 4 operations, or is it fine for it 
>> > to have gaps?
>> 
>> I think filter(_:) and remove(where:) are sufficient. I don’t think we need 
>> to complete the set.
> 
> Based on question (2), I would argue that the answer is yes.
> 
>> > 4. If you are for completing, what should X and Y be called?
>> >
>> 
>> One of the reasons I _don’t_ think we should complete the set is that 
>> formFilter(_:) will take us into serious jumped-the-shark territory, 
>> naming-wise.
>> 
>> I think there’s an argument for never having had filter, and always having 
>> had remove/removed (or possibly select/selected), but don’t think this is 
>> important enough to clear the bar for a rename of this magnitude.
> 
> IMO, they should be called removing(where:) [removed(where:) reads weirdly in 
> conjunction with the preceding receiver] and formFilter(_:). Hundreds of 
> messages finally settled on "form" as the in-place verb of choice where the 
> noun can't ordinarily be verbed. No point in being shy about it now: that's 
> the Swift way, wear it proudly.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Question about async await

[Adam Kemp via swift-evolution]

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 work on any thread. 


I don’t think this is true in general. The purpose of the 
SynchronizationContext abstraction is that it allows for different kinds of 
threading models, and I think the GCD model could work as well. It may be true 
that in a typical C# application using, say, WPF you don’t have that situation. 
In most C# frameworks you basically have the UI thread’s context and then you 
have the generic “thread pool” context. But the way that SynchronizationContext 
works should allow for you to create a GCD-like system. The way it would work 
is that when you enter a queue then you would push a SynchronizationContext for 
that queue, and when you exit the queue you would pop it (restore the previous 
context). The SynchronizationContext for the queue would implement the Post and 
Send methods to dispatch_async and dispatch_sync, respectively.

Again, it may be true that a typical C# application doesn’t need this, but I 
don’t think there’s anything blocking a GCD-like implementation on C# using 
their system. It’s pretty flexible. I believe a similar system could work for 
Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 <
> swift-evolution@swift.org> wrote:
> >
> > 1. Is it right to assert that with a “removing” operation, the closure
> should return `true` for removal?
>
> Yes. If the closure returned false for removal a different, less readable,
> name would be needed for the method.
>

Agree, yes.

> 2. Is it likely that users will want to switch from out-of- to in-place,
> and if so, will having to flip the closure cause confusion/bugs?
>
> I don’t think so. While the argument for an in-place remove is partly that
> it’s more efficient than x = x.filter (in addition to
> reability/discoverability benefits), I think that once both an in- and
> out-of-place version are available, users will reach immediately for the
> one they want. The scenario where you were filtering, and then you realize
> you could do it in-place more efficiently, doesn’t seem to me like it will
> come up in day-to-day use.
>

Unsure. Maybe and maybe, but I think the confusion/bugs would be limited if
the full matrix of four operations exist.


> > 3. Should we “complete” the matrix of 4 operations, or is it fine for it
> to have gaps?
>
> I think filter(_:) and remove(where:) are sufficient. I don’t think we
> need to complete the set.


Based on question (2), I would argue that the answer is yes.

> 4. If you are for completing, what should X and Y be called?
> >
>
> One of the reasons I _don’t_ think we should complete the set is that
> formFilter(_:) will take us into serious jumped-the-shark territory,
> naming-wise.
>
> I think there’s an argument for never having had filter, and always having
> had remove/removed (or possibly select/selected), but don’t think this is
> important enough to clear the bar for a rename of this magnitude.


IMO, they should be called removing(where:) [removed(where:) reads weirdly
in conjunction with the preceding receiver] and formFilter(_:). Hundreds of
messages finally settled on "form" as the in-place verb of choice where the
noun can't ordinarily be verbed. No point in being shy about it now: that's
the Swift way, wear it proudly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 : PRNG. “Reproducible” is not the right word.
> Based on my understanding, some CSPRNGs can be “reproducible” if the seed
> is known; what makes it cryptographically secure is that observing its
> previous *outputs* does not provide information useful to predict future
> outputs. Along those lines, it may be important to securely delete the seed
> from memory as soon as possible; there is some way of doing so in C (it’s
> used in the ChaCha20 reference implementation) but I don’t believe any way
> of doing so in Swift.
>
>
> It's possible to use a CSPRNG-grade algorithm and seed it once to get a
> reproducible sequence, but when you use it as a CSPRNG, you typically feed
> entropy back into it at nondeterministic points to ensure that even if you
> started with a bad seed, you'll eventually get to an alright state. Unless
> you keep track of when entropy was mixed in and what the values were,
> you'll never get a reproducible CSPRNG.
>
> We would give developers a false sense of security if we provided them
> with CSPRNG-grade algorithms that we called CSPRNGs and that they could
> seed themselves. Just because it says "crypto-secure" in the name doesn't
> mean that it'll be crypto-secure if it's seeded with time(). Therefore,
> "reproducible" vs "non-reproducible" looks like a good distinction to me.
>

I disagree here, in two respects:

First, whether or not a particular PRNG is cryptographically secure is an
intrinsic property of the algorithm; whether it's "reproducible" or not is
determined by the published API. In other words, the distinction between
CSPRNG vs. non-CSPRNG is important to document because it's semantics that
cannot be deduced by the user otherwise, and it is an important one for
writing secure code because it tells you whether an attacker can predict
future outputs based only on observing past outputs. "Reproducible" in the
sense of seedable or not is trivially noted by inspection of the published
API, and it is rather immaterial to writing secure code. If your attacker
can observe your seeding once, chances are that they can observe your
reseeding too; then, they can use their own implementation of the PRNG
(whether CSPRNG or non-CSPRNG) and reproduce your pseudorandom sequence
whether or not Swift exposes any particular API.

Secondly, I see no reason to justify the notion that, simply because a PRNG
is cryptographically secure, we ought to hide the seeding initializer
(because one has to exist internally anyway) from the public. Obviously,
one use case for a deterministic PRNG is to get reproducible sequences of
random-appearing values; this can be useful whether the underlying
algorithm is cryptographically secure or not. There are innumerably many
ways to use data generated from a CSPRNG in non-cryptographically secure
ways and omitting or including a public seeding initializer does not change
that; in other words, using a deterministic seed for a CSPRNG would be a
bad idea in certain applications, but it's a deliberate act, and someone
who would mistakenly do that is clearly incapable of *using* the output
from the PRNG in a secure way either; put a third way, you would be hard
pressed to find a situation where it's true that "if only Swift had not
made the seeding initializer public, this author would have written secure
code, but instead the only security hole that existed in the code was
caused by the availability of a public seeding initializer mistakenly
used." The point of having both explicitly instantiable PRNGs and a layer
of simpler APIs like "Int.random()" is so that the less experienced user
can get the "right thing" by default, and the experienced user can
customize the behavior; any user that instantiates his or her own
ChaCha20Random instance is already calling for the power user interface; it
is reasonable to expose the underlying primitive operations (such as
seeding) so long as there are legitimate uses for it.

> * On the issue of consuming entropy: a glaring underlying inconvenience in
> the API needs to be reckoned with. Sometimes, there simply isn’t enough
> entropy to generate another random number. If cryptographic security were
> not default, then it might be OK to fall back to some other method that
> produces a low-quality result. However, if we are to do the secure thing,
> we must decide whether the lack of entropy results in a call to a random
> method to (a) return nil; (b) throw; (c) fatalError; or (d) block. There is
> no way to paper over this problem; not enough entropy means you can’t get a
> random number when you want it. The debate over blocking versus
> non-blocking error, for example, held up the addition of getrandom() to
> Glibc for some time. 

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

[Ben Cohen via swift-evolution]

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 should 
> return `true` for removal?

Yes. If the closure returned false for removal a different, less readable, name 
would be needed for the method.

> 2. Is it likely that users will want to switch from out-of- to in-place, and 
> if so, will having to flip the closure cause confusion/bugs?

I don’t think so. While the argument for an in-place remove is partly that it’s 
more efficient than x = x.filter (in addition to reability/discoverability 
benefits), I think that once both an in- and out-of-place version are 
available, users will reach immediately for the one they want. The scenario 
where you were filtering, and then you realize you could do it in-place more 
efficiently, doesn’t seem to me like it will come up in day-to-day use.

> 3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
> have gaps?

I think filter(_:) and remove(where:) are sufficient. I don’t think we need to 
complete the set.

> 4. If you are for completing, what should X and Y be called?
> 

One of the reasons I _don’t_ think we should complete the set is that 
formFilter(_:) will take us into serious jumped-the-shark territory, 
naming-wise.

I think there’s an argument for never having had filter, and always having had 
remove/removed (or possibly select/selected), but don’t think this is important 
enough to clear the bar for a rename of this magnitude.



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Cohen via swift-evolution]

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:

https://github.com/airspeedswift/swift-evolution/blob/0f4a24d6ded2ab7cb39c1a68e0f92705a7615d73/proposals/-RemoveWhere.md

To keep things simple, this version removes the Equatable version. That could 
be added as a separate proposal.


The issue to resolve is: should the closure have the same polarity as filter, 
and if not, should filter also have an in-place equivalent?
(wait, don’t reply yet, read the rest of the email first :)

From the original proposal:

> `remove(where:)` takes a closure with `true` for elements to remove. `filter` 
> takes a closure with `true` for elements to keep. In both cases, `true` is 
> the "active" case, so likely to be what the user wants without having to 
> apply a negation. The naming of `filter` is unfortunately ambiguous as to 
> whether it’s a removing or keeping operation, but re-considering that is 
> outside the scope of this proposal.


Assuming you accept the premise that a closure returning `true` to `remove` is 
the “right way around” for the argument to an in-place removal operation, this 
means that we have a situation where if you want to flip from in-place to 
out-of-place removal, you have to reverse the closure.

Alternatively, we could duplicate the functionality, and have both filter and 
remove operations have in- and out-of-place variants, completing this 2x2 
matrix:

out-of-place, true to keep: filter(_:)
in-place, true to remove:   remove(where:)
out-of-place, true to remove:   X?
in-place, true to keep: Y?

The names for X that fall easily out of the naming guidelines are 
removed(where:) or removing(where:)

Y is trickier. Normally, the out-of-place would be a variant (like the past 
participle) of the mutating operation, but with filter the out-of-place method 
is already named,* so options are limited. formFilter(_:) is one suggestion.


To help guide feedback on this, here are 4 questions to answer:

1. Is it right to assert that with a “removing” operation, the closure should 
return `true` for removal?
2. Is it likely that users will want to switch from out-of- to in-place, and if 
so, will having to flip the closure cause confusion/bugs?
3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
have gaps?
4. If you are for completing, what should X and Y be called?

Any answers, or further thoughts on any of the above, appreciated.

Ben



* while you could argue that this can be resolved by renaming filter, renames 
like this have a very high bar to clear. Also, filter is a term of art, hence 
its previous exemption from the naming guidelines.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Question about async await

[Jean-Daniel via swift-evolution]

> 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 >> > 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 :
> 
> This doesn't have to be the case, actually.  The intrinsics as Chris 
> described them wouldn't be sufficient, but you could require a "current 
> queue" to be provided when kicking off an async function from scratch, as 
> well as any other "async-local" context information you wanted (e.g. QoS 
> and the other things that Dispatch tracks with attributes/flags that are 
> generally supposed to persist across an entire async operation).
> 
 
 My response was about the ‘implicitly’ part. I hope we will get a rich API 
 that let us specify return queue, QoS and more, but how do you plan to 
 fulfill the « current queue » requirement implicitly ?
>>> 
>>> My earlier response to this thread both linked to a previous thread about 
>>> this and explained how C# does it. It will require some library support, 
>>> but it can be done, and IMO should be done. As I’ve stressed repeatedly, 
>>> async/await without this behavior will be very difficult to use correctly. 
>>> I really hope we don’t settle for that.
>> 
>> In C#, the model is far simple as there is not concept of a single dispatch 
>> queue that can execute work on any thread. You can easily use TLS to store a 
>> default context. Each UI thread can have a context that dispatch completion 
>> on the message queue, but AFAIK,
> 
> 
>> there is not DispatchQueue Local Storage yet.
> 
> There is, see dispatch_queue*_specific()
> 
>> Even something as simple as getting the current queue is not reliable (see 
>> dispatch_get_current_queue man page for details).
> 
> This is a sharp construct for clients, but not for the runtime / compiler 
> that can be taught how not to fall in the traps of this API.
> 
> Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but 
> has two major issues: nesting & refcounting.
> 
> 
> Nesting
> 
> Nesting refers to the fact that when you call code that takes a queue and a 
> callback, you may observe *another* queue:
> 
> run_something_and_call_me_back(arg1, arg2, on_queue, ^{
> assert(dispatch_get_current_queue() == on_queue); // may crash
> ... my stuff ...
> });
> 
> The reason is that run_something_and_call_me_back() may create a queue that 
> targets `on_queue` and then this private queue is what is returned which is 
> both unexpected and exposing internals of the implementation of 
> run_something_and_call_me_back() which is all wrong.
> 
> A corollary is that people attempting to implement recursive locking (which 
> is a bad idea in general anyway) with dispatch_get_current_queue() will fail 
> miserably.
> 
> Refcounting
> 
> Because dispatch has a notion of internal refcount, in ARC world, this will 
> crash most of the time:
> 
> dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
> __strong dispatch_queue cq = dispatch_get_current_queue(); // will 
> usually crash with a resurrection error
> });
> 
> 
> These two edges is why we deprecated this interface for humans.
> 
> 1) A compiler though is not affected by the first issue because the context 
> it would capture would have to not be programatically accessible to clients
> 2) The Swift runtime can know to take "internal" refcounts when capturing 
> this hidden pointer and is not affected by the second problem either.
> 
> 
> tl;dr: what is badly defined is allowing clients to get a pointer to the 
> current queue with a real +1, but that is WAY stronger than what the language 
> runtime needs.
> 
> 
>> That’s why I’m saying it will be difficult to define a reasonable default 
>> context that can be used implicitly.
> 
> This is just not true. This is both easy and reasonable.
> 

I’m glade to be wrong about that point ;-)
One issue I still see is what should be the default when running on a bare 
pthread outside of any queue context. Or is there a queue associated with any 
thread ?


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Question about async await

[Pierre Habouzit via swift-evolution]

> 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 25 sept. 2017 à 21:42, John McCall via swift-evolution 
  a écrit :
 
 This doesn't have to be the case, actually.  The intrinsics as Chris 
 described them wouldn't be sufficient, but you could require a "current 
 queue" to be provided when kicking off an async function from scratch, as 
 well as any other "async-local" context information you wanted (e.g. QoS 
 and the other things that Dispatch tracks with attributes/flags that are 
 generally supposed to persist across an entire async operation).
 
>>> 
>>> My response was about the ‘implicitly’ part. I hope we will get a rich API 
>>> that let us specify return queue, QoS and more, but how do you plan to 
>>> fulfill the « current queue » requirement implicitly ?
>> 
>> My earlier response to this thread both linked to a previous thread about 
>> this and explained how C# does it. It will require some library support, but 
>> it can be done, and IMO should be done. As I’ve stressed repeatedly, 
>> async/await without this behavior will be very difficult to use correctly. I 
>> really hope we don’t settle for that.
> 
> In C#, the model is far simple as there is not concept of a single dispatch 
> queue that can execute work on any thread. You can easily use TLS to store a 
> default context. Each UI thread can have a context that dispatch completion 
> on the message queue, but AFAIK,


> there is not DispatchQueue Local Storage yet.

There is, see dispatch_queue*_specific()

> Even something as simple as getting the current queue is not reliable (see 
> dispatch_get_current_queue man page for details).

This is a sharp construct for clients, but not for the runtime / compiler that 
can be taught how not to fall in the traps of this API.

Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but 
has two major issues: nesting & refcounting.


Nesting

Nesting refers to the fact that when you call code that takes a queue and a 
callback, you may observe *another* queue:

run_something_and_call_me_back(arg1, arg2, on_queue, ^{
assert(dispatch_get_current_queue() == on_queue); // may crash
... my stuff ...
});

The reason is that run_something_and_call_me_back() may create a queue that 
targets `on_queue` and then this private queue is what is returned which is 
both unexpected and exposing internals of the implementation of 
run_something_and_call_me_back() which is all wrong.

A corollary is that people attempting to implement recursive locking (which is 
a bad idea in general anyway) with dispatch_get_current_queue() will fail 
miserably.

Refcounting

Because dispatch has a notion of internal refcount, in ARC world, this will 
crash most of the time:

dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
__strong dispatch_queue cq = dispatch_get_current_queue(); // will usually 
crash with a resurrection error
});


These two edges is why we deprecated this interface for humans.

1) A compiler though is not affected by the first issue because the context it 
would capture would have to not be programatically accessible to clients
2) The Swift runtime can know to take "internal" refcounts when capturing this 
hidden pointer and is not affected by the second problem either.


tl;dr: what is badly defined is allowing clients to get a pointer to the 
current queue with a real +1, but that is WAY stronger than what the language 
runtime needs.


> That’s why I’m saying it will be difficult to define a reasonable default 
> context that can be used implicitly.

This is just not true. This is both easy and reasonable.


-Pierre

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Saagar Jha via swift-evolution]

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:
> 
>   views.remove(where: {$0.isHidden}) //Remove all views which are hidden 
> from the list.
> 
> Another thing which seems to be missing (although it could be there and I 
> don’t know the name) is the ability to split a list into two using a filter 
> (one with the filtered items and one with the remainder).  I am surprised 
> every time I reach for it and it isn’t there (the last time being yesterday). 
>  
> 

There’s partition(by:), which gives you an index that you can split with. 

> Thanks,
> Jon
> 
> 
>> On Sep 25, 2017, at 9:55 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> What is the use case?
>> On Mon, Sep 25, 2017 at 23:27 Félix Cloutier  
>> wrote:
>>> Actually, IMO, it's an oversight that there's no remove(where:), or another 
>>> in-place equivalent to `filter`. I'm in favor of it.
>>> 
>>> Félix
>>> 
>>> 
 Le 25 sept. 2017 à 15:17, Xiaodi Wu  a écrit :
 
 On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu  wrote:
> Brent has a great proposal in the pipeline regularizing the names of some 
> of these functions and filling in some of the more glaring gaps.
> 
> With regard to the specific items proposed here, Felix shows that 
> ‘filter’ provides an idiomatic one-line way of doing some of what is 
> proposed; currently remove(index(of:)) and operating on sliced would 
> accomplish the rest. Therefore, I do not think these proposed additions 
> meet the very high bar for expansion of the standard library API.
 
 I should add, however, it is wonderful (IMO) that more people are thinking 
 about these APIs; welcome and thank you for restarting this very important 
 conversation. It would be nice to get some more eyeballs on the previously 
 discussed set of rationalizations to the Collection APIs so that we can 
 make their use a little more ergonomic--with any luck, some better names 
 for existing extension methods and filling in a very few gaps judiciously 
 would allow us to make the existing facilities sufficiently more 
 discoverable that it will be easier to accomplish what you seek without 
 adding more extensions.
 
 
>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
>>  wrote:
>> Another alternative is to use `array = array.filter { $0 != someElement 
>> }`.
>> 
>> I thought that there would be a `remove(where:)` method, but there isn't.
>> 
>> Félix
>> 
>>> Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
>>>  a écrit :
>>> 
>>> Hello,
>>> 
>>> After going through the Swift standard library functions provided for 
>>> removing elements from a collection, one common pattern can be observed 
>>> in all those functions and that is the functions provide to remove 
>>> elements from the collection by passing the position or index of the 
>>> element or passing a range of indices or positions to remove the 
>>> elements.The standard library does not provide options to remove an 
>>> element from a collection by passing the actual element  to be removed 
>>> directly to the remove method.I've encountered this situation many 
>>> times when programming in Swift wherein I want an element or a set of 
>>> elements to be removed directly without always accessing it's index in 
>>> the collection but I have always ended up having to first access the 
>>> index of the element or elements which I want to remove and then pass 
>>> that index to the remove method.
>>> 
>>> The idea is to have an extension of the RangeReplaceableCollection 
>>> protocol to include a method to remove elements from a collection by 
>>> passing directly the element to be removed to the remove method and 
>>> also include methods to remove multiple elements from the collection by 
>>> passing in a sequence of the elements to be removed to the remove 
>>> method and to remove an element in a particular subrange of the 
>>> collection.
>>> 
>>> The prototype of the methods will be as follows - 
>>> 
>>> extension RangeReplaceableCollection where Element:Equatable{
>>> 
>>> mutating func removeElement(_ elementToBeRemoved:Element){
>>> 
>>> //check if elementToBeRemoved exists ;if yes, remove all occurrences of 
>>> elementsToBeRemoved from the collection.
>>> 
>>> }
>>> 
>>> mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in 
>>> range:Range){
>>> 

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

[Ben Cohen via swift-evolution]

> 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 could see this being extremely useful.  Off the top of my head:
> 
>   views.remove(where: {$0.isHidden}) //Remove all views which are hidden 
> from the list.
> 
> Is such a method ever going to be different (in performance, say) from:
> 
> views = Views(views.lazy.filter { $0.isHidden })

Potentially yes, in a few different ways:

In-place removal doesn’t require an additional storage allocation. Assuming the 
Views type is like Array (or if it is an Array or backed by an Array) then with 
the filter approach, the old buffer would need to be freed, and the new buffer 
allocated.

.lazy.filter is a good way to avoid allocating a temporary array. But you still 
have the issue of not being able to pre-allocate the right amount of storage in 
the target. So either two passes are needed to keep to 1 allocation, or the 
target array will need to reallocate its buffer multiple times as it grows.

When a small number of elements need to be removed, an in-place remove can skip 
to the first element to remove and shuffle the remainder over the top of the 
removed elements. In the extreme version of the above, if there’s nothing to 
remove, then other than that initial scan, the in-place remove is a no-op. By 
contrast, the filter/copy approach is a full copy of every element even when 
there’s nothing to remove.

For in-place removal, a type like Array that is backed by raw memory can 
potentially perform memory moves to shuffle the elements down in-place, helping 
to avoid things like unnecessary arc traffic. When composing the operation from 
higher-level types, you’re relying on the optimizer to eliminate unnecessary 
reference counting. And the more you layer in (like .lazy) the tougher it is 
for the optimizer to do that – it might not even be possible if the type is 
defined behind a barrier like a module boundary etc.

It’s for these reasons I pitched 
https://github.com/apple/swift-evolution/pull/675 previously, but it didn’t 
make it into Swift 4 as we ran out of time. I took an action in the core team 
meeting recently to revisit it wrt to the naming and symmetry with filter. I’ll 
open up a separate thread.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Question about async await

[Jean-Daniel via swift-evolution]

> 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 :
>>> 
>>> This doesn't have to be the case, actually.  The intrinsics as Chris 
>>> described them wouldn't be sufficient, but you could require a "current 
>>> queue" to be provided when kicking off an async function from scratch, as 
>>> well as any other "async-local" context information you wanted (e.g. QoS 
>>> and the other things that Dispatch tracks with attributes/flags that are 
>>> generally supposed to persist across an entire async operation).
>>> 
>> 
>> My response was about the ‘implicitly’ part. I hope we will get a rich API 
>> that let us specify return queue, QoS and more, but how do you plan to 
>> fulfill the « current queue » requirement implicitly ?
> 
> My earlier response to this thread both linked to a previous thread about 
> this and explained how C# does it. It will require some library support, but 
> it can be done, and IMO should be done. As I’ve stressed repeatedly, 
> async/await without this behavior will be very difficult to use correctly. I 
> really hope we don’t settle for that.

In C#, the model is far simple as there is not concept of a single dispatch 
queue that can execute work on any thread. You can easily use TLS to store a 
default context. Each UI thread can have a context that dispatch completion on 
the message queue, but AFAIK, there is not DispatchQueue Local Storage yet. 
Even something as simple as getting the current queue is not reliable (see 
dispatch_get_current_queue man page for details).

That’s why I’m saying it will be difficult to define a reasonable default 
context that can be used implicitly.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

> 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 can be “reproducible” if the seed is 
> known; what makes it cryptographically secure is that observing its previous 
> *outputs* does not provide information useful to predict future outputs. 
> Along those lines, it may be important to securely delete the seed from 
> memory as soon as possible; there is some way of doing so in C (it’s used in 
> the ChaCha20 reference implementation) but I don’t believe any way of doing 
> so in Swift.

It's possible to use a CSPRNG-grade algorithm and seed it once to get a 
reproducible sequence, but when you use it as a CSPRNG, you typically feed 
entropy back into it at nondeterministic points to ensure that even if you 
started with a bad seed, you'll eventually get to an alright state. Unless you 
keep track of when entropy was mixed in and what the values were, you'll never 
get a reproducible CSPRNG.

We would give developers a false sense of security if we provided them with 
CSPRNG-grade algorithms that we called CSPRNGs and that they could seed 
themselves. Just because it says "crypto-secure" in the name doesn't mean that 
it'll be crypto-secure if it's seeded with time(). Therefore, "reproducible" vs 
"non-reproducible" looks like a good distinction to me.

> * On the issue of consuming entropy: a glaring underlying inconvenience in 
> the API needs to be reckoned with. Sometimes, there simply isn’t enough 
> entropy to generate another random number. If cryptographic security were not 
> default, then it might be OK to fall back to some other method that produces 
> a low-quality result. However, if we are to do the secure thing, we must 
> decide whether the lack of entropy results in a call to a random method to 
> (a) return nil; (b) throw; (c) fatalError; or (d) block. There is no way to 
> paper over this problem; not enough entropy means you can’t get a random 
> number when you want it. The debate over blocking versus non-blocking error, 
> for example, held up the addition of getrandom() to Glibc for some time. In 
> my proposed design, initializing a PRNG from the system’s secure stream of 
> random bytes is failable; therefore, a user can choose how to handle the lack 
> of entropy. However, it is desirable to have a thread-local CSPRNG that is 
> used for calls, say, to Int.random(). It would be unfortunate if Int.random() 
> itself was failable; however, that leads to an uncomfortable question: if 
> there is insufficient entropy, should Int.random() block or fatalError? That 
> seems pretty terrible too. However, one cannot simply write this off as an 
> edge case: if this is to be a robust part of the standard library, it must do 
> the “right” thing. Particularly if Swift is to be a true systems programming 
> language and it must accommodate the case when a system is first booted and 
> there is very little entropy.

That's not really the case anymore these days. You're probably thinking of 
/dev/urandom vs. /dev/random. On Darwin, they're the same thing and never run 
out (see man urandom). On Linux, the state of the art is that you leave 
/dev/random alone. Don't take it from me, Prof. Daniel J. Bernstein 
 wrote this 
 a while 
ago:

> Think about this for a moment: whoever wrote the /dev/random manual page 
> seems to simultaneously believe that
> 
>(1) we can't figure out how to deterministically expand one 256-bit 
> /dev/random output into an endless stream of unpredictable keys (this is what 
> we need from urandom), but
> 
>(2) we _can_ figure out how to use a single key to safely encrypt many 
> messages (this is what we need from SSL, PGP, etc.).
> 
> For a cryptographer this doesn't even pass the laugh test.

So that shouldn't be too concerning.

> * What should the default CSPRNG be? There are good arguments for using a 
> cryptographically secure device random. (In my proposed implementation, for 
> device random, I use Security.framework on Apple platforms (because 
> /dev/urandom is not guaranteed to be available due to the sandbox, IIUC). On 
> Linux platforms, I would prefer to use getrandom() and avoid using file 
> system APIs, but getrandom() is new and unsupported on some versions of 
> Ubuntu that Swift supports. This is an issue in and of itself.) Now, a number 
> of these facilities strictly limit or do not guarantee availability of more 
> than a small number of random bytes at a time; they are recommended for 
> seeding other PRNGs but *not* as a routine source of random numbers. 
> Therefore, although device random should be available to users, it probably 
> shouldn’t be the default for the 

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

[Xiaodi Wu via swift-evolution]

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, not just the algorithms that we intend to implement, but the
implementations themselves. This is not at all trivial. We will also need
to specify whether extension methods that generate certain distributions,
etc., are guaranteed secure against side channel attacks where such
implementations are known possible but more expensive.

* Without attempting to bikeshed, the use of the word “Source” is
potentially confusing; it could suggest that the conforming type is a
source of entropy when in fact it consumes entropy. In my proposed design,
the protocol is simply named “PRNG” with an emphasis on the P (i.e.
pseudorandom, not random).

* 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 can be “reproducible” if the seed
is known; what makes it cryptographically secure is that observing its
previous *outputs* does not provide information useful to predict future
outputs. Along those lines, it may be important to securely delete the seed
from memory as soon as possible; there is some way of doing so in C (it’s
used in the ChaCha20 reference implementation) but I don’t believe any way
of doing so in Swift.

* On the issue of consuming entropy: a glaring underlying inconvenience in
the API needs to be reckoned with. Sometimes, there simply isn’t enough
entropy to generate another random number. If cryptographic security were
not default, then it might be OK to fall back to some other method that
produces a low-quality result. However, if we are to do the secure thing,
we must decide whether the lack of entropy results in a call to a random
method to (a) return nil; (b) throw; (c) fatalError; or (d) block. There is
no way to paper over this problem; not enough entropy means you can’t get a
random number when you want it. The debate over blocking versus
non-blocking error, for example, held up the addition of getrandom() to
Glibc for some time. In my proposed design, initializing a PRNG from the
system’s secure stream of random bytes is failable; therefore, a user can
choose how to handle the lack of entropy. However, it is desirable to have
a thread-local CSPRNG that is used for calls, say, to Int.random(). It
would be unfortunate if Int.random() itself was failable; however, that
leads to an uncomfortable question: if there is insufficient entropy,
should Int.random() block or fatalError? That seems pretty terrible too.
However, one cannot simply write this off as an edge case: if this is to be
a robust part of the standard library, it must do the “right” thing.
Particularly if Swift is to be a true systems programming language and it
must accommodate the case when a system is first booted and there is very
little entropy.

* What should the default CSPRNG be? There are good arguments for using a
cryptographically secure device random. (In my proposed implementation, for
device random, I use Security.framework on Apple platforms (because
/dev/urandom is not guaranteed to be available due to the sandbox, IIUC).
On Linux platforms, I would prefer to use getrandom() and avoid using file
system APIs, but getrandom() is new and unsupported on some versions of
Ubuntu that Swift supports. This is an issue in and of itself.) Now, a
number of these facilities strictly limit or do not guarantee availability
of more than a small number of random bytes at a time; they are recommended
for seeding other PRNGs but *not* as a routine source of random numbers.
Therefore, although device random should be available to users, it probably
shouldn’t be the default for the Swift standard library as it could have
negative consequences for the system as a whole. There follows the
significant task of implementing a CSPRNG correctly and securely for the
default PRNG.

* It is well settled, based on math and precedent in other languages such
as C++ and Python, that Int.random() should return a number between Int.min
and Int.max, inclusive, and that Float.random() should return a number in
the range 0..<1 (note the exclusive upper bound). There are good
mathematical reasons for this and computational ones, and having these two
primitives as well as raw random bytes allows the implementation of other
distributions. It is, however, not trivial to implement Float.random()
correctly so as never to generate the value 1. Of course, it should be
possible for people to get a random value in a range with a syntax such as
Int.random(in: 0...4), and this is trivial to implement on top of the
primitive standard uniform distribution.

* “Coin flip” is the Bernoulli distribution with p = 0.5 (i.e. a fair coin,
vs. coins biased 

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

[Alwyn Concessao via swift-evolution]

 
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:  
 
 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 swift-evolution 
 wrote:

Actually, IMO, it's an oversight that there's no remove(where:), or another 
in-place equivalent to `filter`. I'm in favor of it.
Félix


Le 25 sept. 2017 à 15:17, Xiaodi Wu  a écrit :
On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu  wrote:

Brent has a great proposal in the pipeline regularizing the names of some of 
these functions and filling in some of the more glaring gaps.

With regard to the specific items proposed here, Felix shows that ‘filter’ 
provides an idiomatic one-line way of doing some of what is proposed; currently 
remove(index(of:)) and operating on sliced would accomplish the rest. 
Therefore, I do not think these proposed additions meet the very high bar for 
expansion of the standard library API.

I should add, however, it is wonderful (IMO) that more people are thinking 
about these APIs; welcome and thank you for restarting this very important 
conversation. It would be nice to get some more eyeballs on the previously 
discussed set of rationalizations to the Collection APIs so that we can make 
their use a little more ergonomic--with any luck, some better names for 
existing extension methods and filling in a very few gaps judiciously would 
allow us to make the existing facilities sufficiently more discoverable that it 
will be easier to accomplish what you seek without adding more extensions.


On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
 wrote:

Another alternative is to use `array = array.filter { $0 != someElement }`.
I thought that there would be a `remove(where:)` method, but there isn't.
Félix

Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
 a écrit :
Hello,
After going through the Swift standard library functions provided for removing 
elements from a collection, one common pattern can be observed in all those 
functions and that is the functions provide to remove elements from the 
collection by passing the position or index of the element or passing a range 
of indices or positions to remove the elements.The standard library does not 
provide options to remove an element from a collection by passing the actual 
element  to be removed directly to the remove method.I've encountered this 
situation many times when programming in Swift wherein I want an element or a 
set of elements to be removed directly without always accessing it's index in 
the collection but I have always ended up having to first access the index of 
the element or elements which I want to remove and then pass that index to the 
remove method.
The idea is to have an extension of the RangeReplaceableCollection protocol to 
include a method to remove elements from a collection by passing directly the 
element to be removed to the remove method and also include methods to remove 
multiple elements from the collection by passing in a sequence of the elements 
to be removed to the remove method and to remove an element in a particular 
subrange of the collection.
The prototype of the methods will be as follows - 
extension RangeReplaceableCollection where Element:Equatable{
mutating func removeElement(_ elementToBeRemoved:Element){
//check if elementToBeRemoved exists ;if yes, remove all occurrences of 
elementsToBeRemoved from the collection.
}
mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in 
range:Range){
//check if elementoBeRemoved exists; if yes, check if the index of 
elementToBeRemoved is part of the subrange, if yes then remove else don't 
remove.
}
mutating func removeContentsOf (_ elementsToBeRemoved:C){
//check if each element in the elementsToBeRemoved sequence exists in the 
collection, if the element exists, remove it.
}
I've implemented the above in the pull request https://github.com/ 
apple/swift/pull/12058 
Any thoughts/suggestions on this are appreciated.
Thanks!
Alwyn







__ _
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/ mailman/listinfo/swift- evolution


__ _
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/ mailman/listinfo/swift- evolution





___
swift-evolution mailing list
swift-evolution@swift.org

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

[Jonathan Hull via swift-evolution]

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)
func mark()->Int
func returnToMark(_ mark:Int) //These could use something like 
an index instead of Int. My version just returns 1 the first time you call 
mark(), 2 the second time, etc...
}

Also, I find that there are just a few primitive types I actually need from a 
random source:

• Double (full coverage of possible values)
• Double (in range of 0…1)
• UInt32

The following are also nice to have (built from the above), and commonly used:

• Bool / CoinFlip
• Int (positive value)
• FixedWidthInteger (of various sizes.  Full coverage of possible values)
• Character/String
• CGFloat

Any other type can be built from these building blocks.  I have a 
RandomSourceCreatable protocol which allows exactly that.  Once you have that, 
you can put a method on random source which allows you to create any conforming 
type:

extension RandomSource {
func next(_ type: T.Type)->T
}

This is extremely useful to create colors, offsets, etc…

One thing we need to definitely consider are constraints which people may want 
on the random value.  For example, should an Int be positive?  Should it be in 
a certain range?  I have a “constraints” parameter on my RandomSourceCreatable 
protocol to handle this, and it works well, but I am not 100% happy with the 
ergonomics.  I also have a variant with an “in range:” parameter that works for 
simple linear types like Ints and Floats.  We could do something like:

extension RandomSource {
func next(_ type: T.Type, in range: 
ClosedRange) -> T 
}

Finally, don’t underestimate the usefulness of coinFlip and func oneIn(_ 
number:UInt)->Bool.  They let you quickly branch based on a random value:

if source.oneIn(100) { //This will be true roughly 1 in 100 times
//Do something occasionally 
}

Thanks,
Jon


> On Sep 25, 2017, at 9:57 PM, Alejandro Alonso via swift-evolution 
>  wrote:
> 
> Hello evolution,
> 
> I am very thankful for all the feedback, and I’ve been working on a design 
> that tries to utilize everybody’s ideas. The link to what I have so far is 
> here: https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1 
> . Please keep 
> in mind this is just a design, no actual implementation as I would most 
> likely need assistance in doing. The default source for randomness will use 
> the OS’s unseeded CSPRNG. This current setup exposes developers to an API 
> that lets them create their own RandomSources on the fly. I want to make the 
> distinction that any existing or new sources of randomness that conform to 
> UnsafeRandomSource are to be considered non cryptographically secure.
> 
> I would love to get this discussion flowing again, and I would love input on 
> the design. A few things I came across with this design is that some may want 
> to use ranges as an argument for the numeric types, RandomAccessCollection 
> returning an optional when getting a random, and how to incorporate an API 
> that allows distributions. I wanted to get input on how you feel about each 
> of these topics as I’m indifferent about them all. I’m in no way saying this 
> is the design we should go for, but I’m simply providing something I think we 
> should build on or talk about.
> 
> - Alejandro
> 
> On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution 
> , wrote:
>> Hello swift evolution, I would like to propose a unified approach to 
>> `random()` in Swift. I have a simple implementation here 
>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5 
>> . This 
>> implementation is a simple wrapper over existing random functions so 
>> existing code bases will not be affected. Also, this approach introduces a 
>> new random feature for Linux users that give them access to upper bounds, as 
>> well as a lower bound for both Glibc and Darwin users. This change would be 
>> implemented within Foundation.
>> 
>> I believe this simple change could have a very positive impact on new 
>> developers learning Swift and experienced developers being able to write 
>> single random declarations.
>> 
>> I’d like to hear about your ideas on this proposal, or any implementation 
>> changes if need be.
>> 
>> - Alejando
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list

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

[Karl Wagner via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> Actually, IMO, it's an oversight that there's no remove(where:), or another 
> in-place equivalent to `filter`. I'm in favor of it.
> 
> Félix
> 
>> Le 25 sept. 2017 à 15:17, Xiaodi Wu > > a écrit :
>> 
>> On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu > > wrote:
>> Brent has a great proposal in the pipeline regularizing the names of some of 
>> these functions and filling in some of the more glaring gaps.
>> 
>> With regard to the specific items proposed here, Felix shows that ‘filter’ 
>> provides an idiomatic one-line way of doing some of what is proposed; 
>> currently remove(index(of:)) and operating on sliced would accomplish the 
>> rest. Therefore, I do not think these proposed additions meet the very high 
>> bar for expansion of the standard library API.
>> 
>> I should add, however, it is wonderful (IMO) that more people are thinking 
>> about these APIs; welcome and thank you for restarting this very important 
>> conversation. It would be nice to get some more eyeballs on the previously 
>> discussed set of rationalizations to the Collection APIs so that we can make 
>> their use a little more ergonomic--with any luck, some better names for 
>> existing extension methods and filling in a very few gaps judiciously would 
>> allow us to make the existing facilities sufficiently more discoverable that 
>> it will be easier to accomplish what you seek without adding more extensions.
>> 
>> 
>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
>> > wrote:
>> Another alternative is to use `array = array.filter { $0 != someElement }`.
>> 
>> I thought that there would be a `remove(where:)` method, but there isn't.
>> 
>> Félix
>> 
>>> Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
>>> > a écrit :
>>> 
>>> Hello,
>>> 
>>> After going through the Swift standard library functions provided for 
>>> removing elements from a collection, one common pattern can be observed in 
>>> all those functions and that is the functions provide to remove elements 
>>> from the collection by passing the position or index of the element or 
>>> passing a range of indices or positions to remove the elements.The standard 
>>> library does not provide options to remove an element from a collection by 
>>> passing the actual element  to be removed directly to the remove 
>>> method.I've encountered this situation many times when programming in Swift 
>>> wherein I want an element or a set of elements to be removed directly 
>>> without always accessing it's index in the collection but I have always 
>>> ended up having to first access the index of the element or elements which 
>>> I want to remove and then pass that index to the remove method.
>>> 
>>> The idea is to have an extension of the RangeReplaceableCollection protocol 
>>> to include a method to remove elements from a collection by passing 
>>> directly the element to be removed to the remove method and also include 
>>> methods to remove multiple elements from the collection by passing in a 
>>> sequence of the elements to be removed to the remove method and to remove 
>>> an element in a particular subrange of the collection.
>>> 
>>> The prototype of the methods will be as follows - 
>>> 
>>> extension RangeReplaceableCollection where Element:Equatable{
>>> 
>>> mutating func removeElement(_ elementToBeRemoved:Element){
>>> 
>>> //check if elementToBeRemoved exists ;if yes, remove all occurrences of 
>>> elementsToBeRemoved from the collection.
>>> 
>>> }
>>> 
>>> mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in 
>>> range:Range){
>>> 
>>> //check if elementoBeRemoved exists; if yes, check if the index of 
>>> elementToBeRemoved is part of the subrange, if yes then remove else don't 
>>> remove.
>>> 
>>> }
>>> 
>>> mutating func removeContentsOf(_ elementsToBeRemoved:C){
>>> 
>>> //check if each element in the elementsToBeRemoved sequence exists in the 
>>> collection, if the element exists, remove it.
>>> 
>>> }
>>> 
>>> I've implemented the above in the pull request 
>>> https://github.com/apple/swift/pull/12058 
>>>  
>>> 
>>> Any thoughts/suggestions on this are appreciated.
>>> 
>>> Thanks!
>>> 
>>> Alwyn
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> 

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

[Xiaodi Wu via swift-evolution]

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 @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.  Here is how it would be used with a use-case from a
> project I was working on this weekend:
>
> var longWords = allWords //A very long list of words passed as a parameter
> let shortWords = longWords.remove(where: {$0.characters.count < 4})
>
> compare that to either filtering twice:
> let longWords = allWords.filter({$0.characters.count >= 4})
> let shortWords = allWords.filter({$0.characters.count < 4}) //We are
> looping over a very long list twice
>
> or what I ended up doing:
>
> var longWords:[String] = []
> var shortWords:[String] = []
> for word in allWords {
> if word.characters.count < 4 {
> shortWords.append(word)
> }else{
> longWords.append(word)
> }
> }
>
>
> Thanks,
> Jon
>
> On Sep 26, 2017, at 2:59 AM, Xiaodi Wu  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 could see this being extremely useful.  Off the top of
>> my head:
>>
>> views.remove(where: {$0.isHidden}) //Remove all views which are hidden
>> from the list.
>>
>
> Is such a method ever going to be different (in performance, say) from:
>
> views = Views(views.lazy.filter { $0.isHidden })
>
> Another thing which seems to be missing (although it could be there and I
>> don’t know the name) is the ability to split a list into two using a filter
>> (one with the filtered items and one with the remainder).  I am surprised
>> every time I reach for it and it isn’t there (the last time being
>> yesterday).
>>
>> Thanks,
>> Jon
>>
>>
>>
>> On Sep 25, 2017, at 9:55 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> What is the use case?
>> On Mon, Sep 25, 2017 at 23:27 Félix Cloutier 
>> wrote:
>>
>>> Actually, IMO, it's an oversight that there's no remove(where:), or
>>> another in-place equivalent to `filter`. I'm in favor of it.
>>>
>>> Félix
>>>
>>>
>>> Le 25 sept. 2017 à 15:17, Xiaodi Wu  a écrit :
>>>
>>> On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu  wrote:
>>>
 Brent has a great proposal in the pipeline regularizing the names of
 some of these functions and filling in some of the more glaring gaps.

 With regard to the specific items proposed here, Felix shows that
 ‘filter’ provides an idiomatic one-line way of doing some of what is
 proposed; currently remove(index(of:)) and operating on sliced would
 accomplish the rest. Therefore, I do not think these proposed additions
 meet the very high bar for expansion of the standard library API.
>>>
>>>
>>> I should add, however, it is wonderful (IMO) that more people are
>>> thinking about these APIs; welcome and thank you for restarting this very
>>> important conversation. It would be nice to get some more eyeballs on the
>>> previously discussed set of rationalizations to the Collection APIs so that
>>> we can make their use a little more ergonomic--with any luck, some better
>>> names for existing extension methods and filling in a very few gaps
>>> judiciously would allow us to make the existing facilities sufficiently
>>> more discoverable that it will be easier to accomplish what you seek
>>> without adding more extensions.
>>>
>>>
>>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution <
 swift-evolution@swift.org> wrote:

> Another alternative is to use `array = array.filter { $0 !=
> someElement }`.
>
> I thought that there would be a `remove(where:)` method, but there
> isn't.
>
> Félix
>
> Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Hello,
>
> After going through the Swift standard library functions provided for
> removing elements from a collection, one common pattern can be observed in
> all those functions and that is the functions provide to remove elements
> from the collection by passing the position or index of the element or
> passing a range of indices or positions to remove the elements.The 
> standard
> library does not provide options to remove an element from a collection by
> passing the actual element  to be removed directly to the remove
> method.I've encountered this situation many times when programming in 
> Swift
> wherein I want an element or a set of elements to be removed directly

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

[Jonathan Hull via swift-evolution]

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.  Here is how it would be used with a use-case from a 
project I was working on this weekend:

var longWords = allWords //A very long list of words passed as a 
parameter
let shortWords = longWords.remove(where: {$0.characters.count < 4})

compare that to either filtering twice:

let longWords = allWords.filter({$0.characters.count >= 4})
let shortWords = allWords.filter({$0.characters.count < 4}) //We are 
looping over a very long list twice

or what I ended up doing:

var longWords:[String] = []
var shortWords:[String] = []
for word in allWords {
if word.characters.count < 4 {
shortWords.append(word)
}else{
longWords.append(word)
}
}


Thanks,
Jon

> On Sep 26, 2017, at 2:59 AM, Xiaodi Wu  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 could see this being extremely useful.  Off the top of my head:
> 
>   views.remove(where: {$0.isHidden}) //Remove all views which are hidden 
> from the list.
> 
> Is such a method ever going to be different (in performance, say) from:
> 
> views = Views(views.lazy.filter { $0.isHidden })
> 
> Another thing which seems to be missing (although it could be there and I 
> don’t know the name) is the ability to split a list into two using a filter 
> (one with the filtered items and one with the remainder).  I am surprised 
> every time I reach for it and it isn’t there (the last time being yesterday). 
>  
> 
> Thanks,
> Jon
> 
> 
> 
>> On Sep 25, 2017, at 9:55 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> What is the use case?
>> On Mon, Sep 25, 2017 at 23:27 Félix Cloutier > > wrote:
>> Actually, IMO, it's an oversight that there's no remove(where:), or another 
>> in-place equivalent to `filter`. I'm in favor of it.
>> 
>> Félix
>> 
>> 
>>> Le 25 sept. 2017 à 15:17, Xiaodi Wu >> > a écrit :
>>> 
>>> On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu >> > wrote:
>>> Brent has a great proposal in the pipeline regularizing the names of some 
>>> of these functions and filling in some of the more glaring gaps.
>>> 
>>> With regard to the specific items proposed here, Felix shows that ‘filter’ 
>>> provides an idiomatic one-line way of doing some of what is proposed; 
>>> currently remove(index(of:)) and operating on sliced would accomplish the 
>>> rest. Therefore, I do not think these proposed additions meet the very high 
>>> bar for expansion of the standard library API.
>>> 
>>> I should add, however, it is wonderful (IMO) that more people are thinking 
>>> about these APIs; welcome and thank you for restarting this very important 
>>> conversation. It would be nice to get some more eyeballs on the previously 
>>> discussed set of rationalizations to the Collection APIs so that we can 
>>> make their use a little more ergonomic--with any luck, some better names 
>>> for existing extension methods and filling in a very few gaps judiciously 
>>> would allow us to make the existing facilities sufficiently more 
>>> discoverable that it will be easier to accomplish what you seek without 
>>> adding more extensions.
>>> 
>>> 
>>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
>>> > wrote:
>>> Another alternative is to use `array = array.filter { $0 != someElement }`.
>>> 
>>> I thought that there would be a `remove(where:)` method, but there isn't.
>>> 
>>> Félix
>>> 
 Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
 > a écrit :
 
 Hello,
 
 After going through the Swift standard library functions provided for 
 removing elements from a collection, one common pattern can be observed in 
 all those functions and that is the functions provide to remove elements 
 from the collection by passing the position or index of the element or 
 passing a range of indices or positions to remove the elements.The 
 standard library does not provide options to remove an element from a 
 collection by passing the actual element  to be removed directly to the 
 remove method.I've encountered this situation many times when programming 

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

[Jonathan Hull via swift-evolution]

> 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 collection and also 
> returns the elements which are removed from the collection?

Hmm… I suppose a remove(where:) that had a @discardableResult of the things 
being removed would be useful in this way.  Not to mention that it would be 
consistent with what I expect from a function called remove.

I was already in support, but now even more so…

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 hidden
> from the list.
>

Is such a method ever going to be different (in performance, say) from:

views = Views(views.lazy.filter { $0.isHidden })

Another thing which seems to be missing (although it could be there and I
> don’t know the name) is the ability to split a list into two using a filter
> (one with the filtered items and one with the remainder).  I am surprised
> every time I reach for it and it isn’t there (the last time being
> yesterday).
>
> Thanks,
> Jon
>
>
>
> On Sep 25, 2017, at 9:55 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> What is the use case?
> On Mon, Sep 25, 2017 at 23:27 Félix Cloutier 
> wrote:
>
>> Actually, IMO, it's an oversight that there's no remove(where:), or
>> another in-place equivalent to `filter`. I'm in favor of it.
>>
>> Félix
>>
>>
>> Le 25 sept. 2017 à 15:17, Xiaodi Wu  a écrit :
>>
>> On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu  wrote:
>>
>>> Brent has a great proposal in the pipeline regularizing the names of
>>> some of these functions and filling in some of the more glaring gaps.
>>>
>>> With regard to the specific items proposed here, Felix shows that
>>> ‘filter’ provides an idiomatic one-line way of doing some of what is
>>> proposed; currently remove(index(of:)) and operating on sliced would
>>> accomplish the rest. Therefore, I do not think these proposed additions
>>> meet the very high bar for expansion of the standard library API.
>>
>>
>> I should add, however, it is wonderful (IMO) that more people are
>> thinking about these APIs; welcome and thank you for restarting this very
>> important conversation. It would be nice to get some more eyeballs on the
>> previously discussed set of rationalizations to the Collection APIs so that
>> we can make their use a little more ergonomic--with any luck, some better
>> names for existing extension methods and filling in a very few gaps
>> judiciously would allow us to make the existing facilities sufficiently
>> more discoverable that it will be easier to accomplish what you seek
>> without adding more extensions.
>>
>>
>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Another alternative is to use `array = array.filter { $0 != someElement
 }`.

 I thought that there would be a `remove(where:)` method, but there
 isn't.

 Félix

 Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution <
 swift-evolution@swift.org> a écrit :

 Hello,

 After going through the Swift standard library functions provided for
 removing elements from a collection, one common pattern can be observed in
 all those functions and that is the functions provide to remove elements
 from the collection by passing the position or index of the element or
 passing a range of indices or positions to remove the elements.The standard
 library does not provide options to remove an element from a collection by
 passing the actual element  to be removed directly to the remove
 method.I've encountered this situation many times when programming in Swift
 wherein I want an element or a set of elements to be removed directly
 without always accessing it's index in the collection but I have always
 ended up having to first access the index of the element or elements which
 I want to remove and then pass that index to the remove method.

 The idea is to have an extension of the RangeReplaceableCollection
 protocol to include a method to remove elements from a collection by
 passing directly the element to be removed to the remove method and also
 include methods to remove multiple elements from the collection by passing
 in a sequence of the elements to be removed to the remove method and to
 remove an element in a particular subrange of the collection.

 The prototype of the methods will be as follows -

 extension RangeReplaceableCollection where Element:Equatable{

 mutating func removeElement(_ elementToBeRemoved:Element){

 //check if elementToBeRemoved exists ;if yes, remove all occurrences of
 elementsToBeRemoved from the collection.

 }

 mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in
 range:Range){

 //check if elementoBeRemoved exists; if yes, check if the index of
 elementToBeRemoved is part of the subrange, if yes then remove else don't
 remove.

 }

 mutating func removeContentsOf(_ elementsToBeRemoved:C){

 //check if each element in the 

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

[Alwyn Concessao via swift-evolution]

 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 also returns 
the elements which are removed from the collection?

@Félix Cloutier and @Robert Bennett -  Yes, in-place filter method is not 
provided by Swift.The in-place filter method would also take care of removing 
elements without actually accessing it's index.
AlwynOn Tuesday, 26 September 2017, 12:00:23 PM IST, Félix Cloutier 
 wrote:  
 
 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 
have a mutating and a non-mutating version of everything. Not sure why we 
should break consistency and not have an in-place version of filter.
Félix


Le 25 sept. 2017 à 21:55, Xiaodi Wu  a écrit :
What is the use case?
On Mon, Sep 25, 2017 at 23:27 Félix Cloutier  wrote:

Actually, IMO, it's an oversight that there's no remove(where:), or another 
in-place equivalent to `filter`. I'm in favor of it.
Félix


Le 25 sept. 2017 à 15:17, Xiaodi Wu  a écrit :
On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu  wrote:

Brent has a great proposal in the pipeline regularizing the names of some of 
these functions and filling in some of the more glaring gaps.

With regard to the specific items proposed here, Felix shows that ‘filter’ 
provides an idiomatic one-line way of doing some of what is proposed; currently 
remove(index(of:)) and operating on sliced would accomplish the rest. 
Therefore, I do not think these proposed additions meet the very high bar for 
expansion of the standard library API.

I should add, however, it is wonderful (IMO) that more people are thinking 
about these APIs; welcome and thank you for restarting this very important 
conversation. It would be nice to get some more eyeballs on the previously 
discussed set of rationalizations to the Collection APIs so that we can make 
their use a little more ergonomic--with any luck, some better names for 
existing extension methods and filling in a very few gaps judiciously would 
allow us to make the existing facilities sufficiently more discoverable that it 
will be easier to accomplish what you seek without adding more extensions.


On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
 wrote:

Another alternative is to use `array = array.filter { $0 != someElement }`.
I thought that there would be a `remove(where:)` method, but there isn't.
Félix

Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
 a écrit :
Hello,
After going through the Swift standard library functions provided for removing 
elements from a collection, one common pattern can be observed in all those 
functions and that is the functions provide to remove elements from the 
collection by passing the position or index of the element or passing a range 
of indices or positions to remove the elements.The standard library does not 
provide options to remove an element from a collection by passing the actual 
element  to be removed directly to the remove method.I've encountered this 
situation many times when programming in Swift wherein I want an element or a 
set of elements to be removed directly without always accessing it's index in 
the collection but I have always ended up having to first access the index of 
the element or elements which I want to remove and then pass that index to the 
remove method.
The idea is to have an extension of the RangeReplaceableCollection protocol to 
include a method to remove elements from a collection by passing directly the 
element to be removed to the remove method and also include methods to remove 
multiple elements from the collection by passing in a sequence of the elements 
to be removed to the remove method and to remove an element in a particular 
subrange of the collection.
The prototype of the methods will be as follows - 
extension RangeReplaceableCollection where Element:Equatable{
mutating func removeElement(_ elementToBeRemoved:Element){
//check if elementToBeRemoved exists ;if yes, remove all occurrences of 
elementsToBeRemoved from the collection.
}
mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in 
range:Range){
//check if elementoBeRemoved exists; if yes, check if the index of 
elementToBeRemoved is part of the subrange, if yes then remove else don't 
remove.
}
mutating func removeContentsOf(_ elementsToBeRemoved:C){
//check if each element in the elementsToBeRemoved sequence exists in 

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

[Félix Cloutier via swift-evolution]

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 problems 
than the one that this tries to avoid. Maybe InsecureRandom? Pseudorandom? 
PredictableRandom?

The subtype relationships seem problematic to me: any UnsafeRandomSource is 
probably also a RandomSource. This means that you can't design an API requiring 
a RandomSource and assume that you'll get a crypto-secure one. Granted, anyone 
can pretend that their random is crypto-secure while it isn't, but I feel like 
this should be an important API hint.

I'm not convinced that `RandomSource` needs a `shared` property. By definition, 
you shouldn't be able to tell which RandomSource instance generated some random 
number, so it doesn't matter if you have multiple instances of it, or just one. 
It could be a flyweight and we'd be none the wiser. Requiring a shared instance 
also forces the implementation to be thread-safe, which is almost certainly not 
a desirable feature for an API meant to have a huge throughput.

To me, the tradeoff between "secure" and "insecure" seems to be that "secure" 
RNGs have an unpredictable result (which is suitable for crypto operations), 
and "insecure" RNGs can be seeded and repeated, which is a desirable feature in 
many scenarios. Then, there are some low-stake cases where that probably 
doesn't really matter (like in a dice-rolling app). That seems to be easy 
enough to represent with a base AnyRandomSource protocol, with sub-protocols 
RandomSource and PseudorandomSource (or whatever else seems to be a better 
name).

I think that there needs to be discussion about the random range for the static 
`random` properties. Right now, it can't return negative values, even for 
signed types. I feel that a random property on a type should use the entire 
domain of that type, and the range random properties can be used when you want 
a specific domain of values. If people aren't sure what Int.random or 
Double.random gets them, they won't use it, so I'd go for the simplest and most 
uniform possible definition for them: any finite value that the type can 
represent. (Also, your FixedWithInteger currently can't return Self.max, which 
I think is a bug.)

I have more comments, but it's getting late, so maybe I'll continue tomorrow.

Félix

> Le 25 sept. 2017 à 21:57, Alejandro Alonso via swift-evolution 
>  a écrit :
> 
> Hello evolution,
> 
> I am very thankful for all the feedback, and I’ve been working on a design 
> that tries to utilize everybody’s ideas. The link to what I have so far is 
> here: https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1 
> . Please keep 
> in mind this is just a design, no actual implementation as I would most 
> likely need assistance in doing. The default source for randomness will use 
> the OS’s unseeded CSPRNG. This current setup exposes developers to an API 
> that lets them create their own RandomSources on the fly. I want to make the 
> distinction that any existing or new sources of randomness that conform to 
> UnsafeRandomSource are to be considered non cryptographically secure.
> 
> I would love to get this discussion flowing again, and I would love input on 
> the design. A few things I came across with this design is that some may want 
> to use ranges as an argument for the numeric types, RandomAccessCollection 
> returning an optional when getting a random, and how to incorporate an API 
> that allows distributions. I wanted to get input on how you feel about each 
> of these topics as I’m indifferent about them all. I’m in no way saying this 
> is the design we should go for, but I’m simply providing something I think we 
> should build on or talk about.
> 
> - Alejandro
> 
> On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution 
> , wrote:
>> Hello swift evolution, I would like to propose a unified approach to 
>> `random()` in Swift. I have a simple implementation here 
>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5 
>> . This 
>> implementation is a simple wrapper over existing random functions so 
>> existing code bases will not be affected. Also, this approach introduces a 
>> new random feature for Linux users that give them access to upper bounds, as 
>> well as a lower bound for both Glibc and Darwin users. This change would be 
>> implemented within Foundation.
>> 
>> I believe this simple change could have a very positive impact on new 
>> developers learning Swift and experienced developers being able to write 
>> single random declarations.
>> 
>> I’d like to hear about your ideas on this proposal, or any 

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

[Howard Lovatt via swift-evolution]

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 with multiple code bases.

On Mon, 25 Sep 2017 at 8:38 am, Benjamin Garrigues via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > Le 24 sept. 2017 à 21:15, Marc Schlichte via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> > I hope we come up with some genuine ideas for ReactiveStreams on Swift.
> >
> > For example instead of onNext()/onError() we could have a single method
> which takes a Result Monad. ARC memory management might require Swift
> specific solutions too.
> >
> > Also on the mindset: Often I see my Android colleagues using Observables
> to wait for the completion of asynchronous requests. But I think these
> control flow scenarios are better handled by async/await instead.
> >
> > Reactive should be used when a component (class / actor) wants to make
> an unsolicited 'upcall'. As such it is firstly a modern variant of
> KVO/NotificatonCenter/Delegates/target-action etc. with the additional
> ability to transform / combine / schedule signals on the way from the
> signal producers to the signal consumers (signal stream processing).
> >
> > As KVO/Delegates probably won't work correctly for Actors (because of
> execution context discrepancy), a reactive replacement working well with
> Actors is definitely needed.
>
> i only had a little bit of rx experience but this one made me curious :
> why would reactive programming be a requirement for "one to one, at most
> once , best effort message delivery" between actors ? ( which iirc should
> be the only guarantee for actor to actor communication).
> Rx is a very broad and generic abstraction for asynchronous
> communications, which brings its own share of novel issues ( at least
> judging by my personnal experience and the horror stories of people around
> me), whereas actors aim at being the most simple and straightforward way to
> handle concurrency and state, by acknowledging where the states should live
> and mutate and which shortcomings in the communication between actors have
> to be expected.
>
>
>
>
>
> >
> > It would be great if a Swift reactive library would allow us to  design
> ViewModels (cf MVVM) as Actors and support 2 way bindings to the UI.
> >
> > Cheers
> > Marc
> >
> >
> >
> >  Ursprüngliche Nachricht
> > Von: swift-evolution@swift.org
> > Gesendet: 24. September 2017 4:36 vorm.
> > An: swift-evolution@swift.org
> > Antworten: mat...@gmail.com
> > Betreff: Re: [swift-evolution] Standard ReactiveSteam definitions for
> Swift
> >
> > Some thoughts as a programmer who has written an atypical reactive
> programming library...
> >
> > You're providing protocols that strongly imply ReactiveX semantics.
> >
> > Some libraries (like my own CwlSignal) look a little like ReactiveX (in
> that CwlSignal implements all of the ReactiveX operators) but have some
> quite different semantics during graph construction and during other
> lifecycle events. For example, CwlSignal doesn't have public Subscriber
> concept (responsibilities are split between the private `SignalHandler` and
> the `SignalSender` interface) and while the core `Signal` class is a
> Publisher-like concept, it is single-use which would make it a very weird
> implementation of this `Publisher` protocol.
> >
> > These differences can make protocols for interoperability a bit of a
> loaded shotgun. Joining two arbitrary libraries together is likely to cause
> problems when the libraries have different expectations.
> >
> > In some respects, it would be better to have a single, standard,
> concrete implementation of a class that takes an event stream input and
> emits an event stream. This is sometimes called a PublishSubject. A
> generalized PublishSubject could act as the glue between different
> libraries on the input and output sides. That way, the semantics of the
> interoperability point are fixed and each library need only ensure they
> support the interoperability point, rather than the semantics of every
> other library that could be on the other side of a protocol.
> >
> > To me, I feel like this would best be implemented as part of Actor model
> concurrency – taking inputs and emitting outputs is fundamentally what
> Actors *do*.
> >
> > As for naming... I would *not* recommend using `Flow` it is far too
> generic, has been used in very different contexts and doesn't match
> terminology in the field. It's fine for a library to break with common
> terminology for its own purposes but an interoperability interface must use
> the established terminology. `Publisher` and `Subscriber` are fairly clear
> in context but can mean very different things *outside* of reactive
> programming. `Observable` and `Observer` are clearer but again, the
> `Observer` 

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

[Howard Lovatt via swift-evolution]

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 ideas for ReactiveStreams on Swift.
>
> For example instead of onNext()/onError() we could have a single method
> which takes a Result Monad. ARC memory management might require Swift
> specific solutions too.
>
> Also on the mindset: Often I see my Android colleagues using Observables
> to wait for the completion of asynchronous requests. But I think these
> control flow scenarios are better handled by async/await instead.
>
> Reactive should be used when a component (class / actor) wants to make an
> unsolicited 'upcall'. As such it is firstly a modern variant of
> KVO/NotificatonCenter/Delegates/target-action etc. with the additional
> ability to transform / combine / schedule signals on the way from the
> signal producers to the signal consumers (signal stream processing).
>
> As KVO/Delegates probably won't work correctly for Actors (because of
> execution context discrepancy), a reactive replacement working well with
> Actors is definitely needed.
>
> It would be great if a Swift reactive library would allow us to  design
> ViewModels (cf MVVM) as Actors and support 2 way bindings to the UI.
>
> Cheers
> Marc
>
>
>
>   Ursprüngliche Nachricht
> Von: swift-evolution@swift.org
> Gesendet: 24. September 2017 4:36 vorm.
> An: swift-evolution@swift.org
> Antworten: mat...@gmail.com
> Betreff: Re: [swift-evolution] Standard ReactiveSteam definitions for Swift
>
> Some thoughts as a programmer who has written an atypical reactive
> programming library...
>
> You're providing protocols that strongly imply ReactiveX semantics.
>
> Some libraries (like my own CwlSignal) look a little like ReactiveX (in
> that CwlSignal implements all of the ReactiveX operators) but have some
> quite different semantics during graph construction and during other
> lifecycle events. For example, CwlSignal doesn't have public Subscriber
> concept (responsibilities are split between the private `SignalHandler` and
> the `SignalSender` interface) and while the core `Signal` class is a
> Publisher-like concept, it is single-use which would make it a very weird
> implementation of this `Publisher` protocol.
>
> These differences can make protocols for interoperability a bit of a
> loaded shotgun. Joining two arbitrary libraries together is likely to cause
> problems when the libraries have different expectations.
>
> In some respects, it would be better to have a single, standard, concrete
> implementation of a class that takes an event stream input and emits an
> event stream. This is sometimes called a PublishSubject. A generalized
> PublishSubject could act as the glue between different libraries on the
> input and output sides. That way, the semantics of the interoperability
> point are fixed and each library need only ensure they support the
> interoperability point, rather than the semantics of every other library
> that could be on the other side of a protocol.
>
> To me, I feel like this would best be implemented as part of Actor model
> concurrency – taking inputs and emitting outputs is fundamentally what
> Actors *do*.
>
> As for naming... I would *not* recommend using `Flow` it is far too
> generic, has been used in very different contexts and doesn't match
> terminology in the field. It's fine for a library to break with common
> terminology for its own purposes but an interoperability interface must use
> the established terminology. `Publisher` and `Subscriber` are fairly clear
> in context but can mean very different things *outside* of reactive
> programming. `Observable` and `Observer` are clearer but again, the
> `Observer` pattern in general programming is not the same as a reactive
> programming `Observer` so putting it in the Swift standard library would
> annoy some people. On an aesthetic note, I've always found `Observer` and
> `Observable` difficult to read – they are similar enough that I confuse
> inputs and outputs when I'm tired. This is one of the reasons these terms
> do not appear in my library.
>
> My personal vote is that this topic simply can't be addressed by the
> standard library at this point. This is something where interoperability
> with Swift's Actor Model should be a primary concern and until it's done,
> any action now is only likely to be a headache later.
>
> Cheers,
> Matt Gallagher.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-- Howard.
___
swift-evolution 

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

[Howard Lovatt via swift-evolution]

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.


ReactiveX can be built upon Reactive Streams, e.g. RxJava 2.0., but the
idea of Reactive Streams is that the protocol is so low level you don’t
interact directly with them. They seem compatible with many different
styles including actors, e.g. Akka (the Akka people destined Reactive
Streams I think). Reactive Streams are very actor like with one way
communication links that transfer a copy of single items/errors or no
items/error (pure messages).


> Some libraries (like my own CwlSignal) look a little like ReactiveX (in
> that CwlSignal implements all of the ReactiveX operators) but have some
> quite different semantics during graph construction and during other
> lifecycle events. For example, CwlSignal doesn't have public Subscriber
> concept (responsibilities are split between the private `SignalHandler` and
> the `SignalSender` interface) and while the core `Signal` class is a
> Publisher-like concept, it is single-use which would make it a very weird
> implementation of this `Publisher` protocol.


Nothing in the Reactive Stream specification to prevent single use
Publishers, Subscribers, or Processors. The Reactive Stream specification
only talks about the communication and error reporting. As long as your
library has the concept of a subscription of some form you can probably
write translators to the 3 protocols.


> These differences can make protocols for interoperability a bit of a
> loaded shotgun. Joining two arbitrary libraries together is likely to cause
> problems when the libraries have different expectations.


Seems to work OK in the Java world, people use Akka and RxJava together.


> In some respects, it would be better to have a single, standard, concrete
> implementation of a class that takes an event stream input and emits an
> event stream. This is sometimes called a PublishSubject. A generalized
> PublishSubject could act as the glue between different libraries on the
> input and output sides. That way, the semantics of the interoperability
> point are fixed and each library need only ensure they support the
> interoperability point, rather than the semantics of every other library
> that could be on the other side of a protocol.


This is what Reactive Streams are. They just tell you how to hook things
up, how to ask for items, how to report errors, and how to finish with a
connection. They do not dictate the semantics at the other end. For example
your translator could throw fatal exception on an error if your library
didn’t report errors or wrap the error in a Result type if it handled error
in a functional way.


> To me, I feel like this would best be implemented as part of Actor model
> concurrency – taking inputs and emitting outputs is fundamentally what
> Actors *do*.


As I have said they are very actor like and I think it was the Akka people
who came up with the specification therefore I am not sure you are locking
anything out. If the Swift actor model can’t interact with something as
simple as Reactive Streams it will not interact with anything other than
other Swift Actors, which would be very limiting. For example you would
expect the Swift actors to interact with GCD, perhaps via suitable
wrappers.


> As for naming... I would *not* recommend using `Flow` it is far too
> generic, has been used in very different contexts and doesn't match
> terminology in the field. It's fine for a library to break with common
> terminology for its own purposes but an interoperability interface must use
> the established terminology. `Publisher` and `Subscriber` are fairly clear
> in context but can mean very different things *outside* of reactive
> programming. `Observable` and `Observer` are clearer but again, the
> `Observer` pattern in general programming is not the same as a reactive
> programming `Observer` so putting it in the Swift standard library would
> annoy some people. On an aesthetic note, I've always found `Observer` and
> `Observable` difficult to read – they are similar enough that I confuse
> inputs and outputs when I'm tired. This is one of the reasons these terms
> do not appear in my library.
>
> My personal vote is that this topic simply can't be addressed by the
> standard library at this point. This is something where interoperability
> with Swift's Actor Model should be a primary concern and until it's done,
> any action now is only likely to be a headache later.


I would prefer to move forward more quickly, I don’t think there is much
risk since the specification is so low level and flexible. The whitpaper
from Chris Lattner also mentions that it would be desirable for any Actor
system in Swift to be compatible with Reactive Streams, so why not start
now.


>
> 

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

[Félix Cloutier via swift-evolution]

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 
have a mutating and a non-mutating version of everything. Not sure why we 
should break consistency and not have an in-place version of filter.

Félix

> Le 25 sept. 2017 à 21:55, Xiaodi Wu  a écrit :
> 
> What is the use case?
> On Mon, Sep 25, 2017 at 23:27 Félix Cloutier  > wrote:
> Actually, IMO, it's an oversight that there's no remove(where:), or another 
> in-place equivalent to `filter`. I'm in favor of it.
> 
> Félix
> 
> 
>> Le 25 sept. 2017 à 15:17, Xiaodi Wu > > a écrit :
>> 
>> On Mon, Sep 25, 2017 at 4:55 PM, Xiaodi Wu > > wrote:
>> Brent has a great proposal in the pipeline regularizing the names of some of 
>> these functions and filling in some of the more glaring gaps.
>> 
>> With regard to the specific items proposed here, Felix shows that ‘filter’ 
>> provides an idiomatic one-line way of doing some of what is proposed; 
>> currently remove(index(of:)) and operating on sliced would accomplish the 
>> rest. Therefore, I do not think these proposed additions meet the very high 
>> bar for expansion of the standard library API.
>> 
>> I should add, however, it is wonderful (IMO) that more people are thinking 
>> about these APIs; welcome and thank you for restarting this very important 
>> conversation. It would be nice to get some more eyeballs on the previously 
>> discussed set of rationalizations to the Collection APIs so that we can make 
>> their use a little more ergonomic--with any luck, some better names for 
>> existing extension methods and filling in a very few gaps judiciously would 
>> allow us to make the existing facilities sufficiently more discoverable that 
>> it will be easier to accomplish what you seek without adding more extensions.
>> 
>> 
>> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution 
>> > wrote:
>> Another alternative is to use `array = array.filter { $0 != someElement }`.
>> 
>> I thought that there would be a `remove(where:)` method, but there isn't.
>> 
>> Félix
>> 
>>> Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution 
>>> > a écrit :
>>> 
>>> Hello,
>>> 
>>> After going through the Swift standard library functions provided for 
>>> removing elements from a collection, one common pattern can be observed in 
>>> all those functions and that is the functions provide to remove elements 
>>> from the collection by passing the position or index of the element or 
>>> passing a range of indices or positions to remove the elements.The standard 
>>> library does not provide options to remove an element from a collection by 
>>> passing the actual element  to be removed directly to the remove 
>>> method.I've encountered this situation many times when programming in Swift 
>>> wherein I want an element or a set of elements to be removed directly 
>>> without always accessing it's index in the collection but I have always 
>>> ended up having to first access the index of the element or elements which 
>>> I want to remove and then pass that index to the remove method.
>>> 
>>> The idea is to have an extension of the RangeReplaceableCollection protocol 
>>> to include a method to remove elements from a collection by passing 
>>> directly the element to be removed to the remove method and also include 
>>> methods to remove multiple elements from the collection by passing in a 
>>> sequence of the elements to be removed to the remove method and to remove 
>>> an element in a particular subrange of the collection.
>>> 
>>> The prototype of the methods will be as follows - 
>>> 
>>> extension RangeReplaceableCollection where Element:Equatable{
>>> 
>>> mutating func removeElement(_ elementToBeRemoved:Element){
>>> 
>>> //check if elementToBeRemoved exists ;if yes, remove all occurrences of 
>>> elementsToBeRemoved from the collection.
>>> 
>>> }
>>> 
>>> mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in 
>>> range:Range){
>>> 
>>> //check if elementoBeRemoved exists; if yes, check if the index of 
>>> elementToBeRemoved is part of the subrange, if yes then remove else don't 
>>> remove.
>>> 
>>> }
>>> 
>>> mutating func removeContentsOf(_ elementsToBeRemoved:C){
>>> 
>>> //check if each element in the elementsToBeRemoved sequence exists in the 
>>> collection, if the element exists, remove it.
>>> 
>>> }
>>> 
>>> I've implemented the above in the pull request 
>>> https://github.com/apple/swift/pull/12058 
>>> 

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

[Howard Lovatt via swift-evolution]

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 on(next:) nor on(error:) accept a closure, they take values.

  3. You don’t manually call either on(next:) or on(error:), the only
method you interact with is subscribe. Which in my library I have
overloaded with ~~> so that you don’t call methods at all on reactive
stream objects. See README for
https://github.com/hlovatt/Concurrency-Utilities.

Hello World using this library is:

let helloWorldPublisher = ForEachPublisher(sequence: "Hello, world!".characters)
let helloWorldSubscriber = ReduceSubscriberFuture(into: "") { (result:
inout String, next: Character) in
result.append(next)
}
var helloWorldResult = "Failed!" // Default value for failure, timeout, etc.
helloWorldPublisher ~~> helloWorldSubscriber ~~>? helloWorldResult

Note how the arguments to ForEachProducer and ReduceSubscriberFuture mimic
those to similarly named methods in Swifts Sequence protocol, how Subscriber
's ~~> is evocative of the process that is occurring, and how Future's
~~>? looks
natural and controls execution and error reporting. Fire is another part of
the library, see readme.



On Sun, 24 Sep 2017 at 12:25 am, Dave DeLong via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Sep 23, 2017, at 1:24 AM, Georgios Moschovitis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Copied from the corresponding Github issue, I would like to hear opinions
> from the broader community on this:
>
> I am wondering if the correct 'translation' to Swift of:
>
> ```
> onNext()
> onError()
> ```
>
> is really:
>
> ```
> on(next:)
> on(error:)
> ```
>
>
> I’ve played around with reactive streams, and one of the main issues with
> this naming convention is that it really confuses the compiler when you try
> to use trailing closure syntax:
>
> aStream.on { nextOrError in
>
> }
>
> The compiler has a really hard time inferring what the type of nextOrError
> is without explicitly typing the parameter or not using trailing closure
> syntax.
>
> Using .onNext { … } or .onError { … } bypasses this problem entirely.
>
> Dave
>
>
> maybe something closer to Foundation's naming conventions would be:
>
> ```
> didReceive(next:) or didReceive(value:)
> didReceive(error:)
> ```
>
> -g.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-- Howard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

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 the Swift community to
decide.

You could also change the names of the protocols, but that would make
standard documents and code from other languages hard to follow.

On Fri, 22 Sep 2017 at 3:11 am, Georgios Moschovitis <
george.moschovi...@icloud.com> wrote:

> +1
>
> Btw, I kinda like the `Flow` name (or even `Observable`). Don’t like
> `ReactiveStream` at all.
>
> -g.
>
> On 19 Sep 2017, at 3:59 AM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> http://www.reactive-streams.org/
>
>
> --
-- Howard.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution