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

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

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

h 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. &g

Re: [swift-evolution] (core library) modern URL types

; > On Aug 21, 2017, at 11:24 AM, Félix Cloutier via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> There's no question that there's a lot in common between file: URLs and >> other URLs, but that hardly makes URLs

Re: [swift-evolution] (core library) modern URL types

There's no question that there's a lot in common between file: URLs and other URLs, but that hardly makes URLs better in the file: case. I saw the enum. The problem remains that it's a common API principle to accept the broadest possible input. It's not fundamentally wrong to accept and resolve

Re: [swift-evolution] Two thoughts on concurrency

I feel that it's important to point out that this example feels weird because even though the compiler doesn't treat "weak" as a reserved term, most developers perceive it as one. I don't think that David is worried that we're taking away all the cool words from the realm of identifiers; the

Re: [swift-evolution] await keyword "scope"

I don't believe that having "await" everywhere will remind you that you have to precalculate and cache operands to suspending operations. In fact, it sounds like your goal is not to enforce that every async operation is gated behind `await`, but to ensure that developers cache the operands of

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

If all the hard symbols are automatically converted by the editor, why can't the editor show you a "pretty" view and save as "regular" text? Why does it need compiler involvement if the problem can entirely be addressed in UI space? > Le 29 août 2017 à 06:14, John Pratt via swift-evolution >

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

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

Re: [swift-evolution] Optional Argument Chaining

You talk about flatMap without giving an example. The readme isn't that bad with it, IMO: if let readme = String(contentsOfFile: "README.md").flatMap(Markdown) { // use contents here } That doesn't work when you need multiple optional parameters. In my own experience, that hasn't been

Re: [swift-evolution] Opaque Pointers in Swift

Could you do a conditional typealias? #if OPENSSL_HAS_OPAQUE_POINTERS typealias OpenSSLContext = OpaquePointer #else typealias OpenSSLContext = UnsafeMutablePointer #endif Then as long as you don't need to build one single OpenSSL that supports both, you'll be fine (although it might work

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

I agree with the common theme that `@abiPublic` is weird. I imagine that not a lot of `@abiPublic` symbols actually want to be internal: they'll almost all be implementation details that really want to be `private` or `fileprivate` but that have to be `internal` to satisfy what (I believe) most

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

In addition to what Chris said: enums imported from C and @objc enums can both have extensions and conform to protocols, so IMO it should be legal to write something like `extension Foundation.ComparisonResult: ValueEnumerable {}`. Félix > Le 30 déc. 2017 à 19:00, Jacob Bandes-Storch via

Re: [swift-evolution] Renaming SwiftObject

I'll bite. Shouldn't that name encode that it's an Objective-C object? Like Swift.ObjCBase? > Le 4 janv. 2018 à 22:10, Greg Parker via swift-evolution > a écrit : > > SwiftObject is an Objective-C class that is the base class of all "pure > Swift" class types. It

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

I'm not sure how much background you have into this thread, but the idea of sources and distributions was rejected months ago as almost always too cumbersome given that people overwhelmingly want uniform random numbers. I agree that random() is better as a method. I also think that the default

[swift-evolution] Why doesn't enum destructuring use guaranteed references?

Running this on my MBP with 10 as the parameter: https://gist.github.com/zneak/ae33bb970a08632cfb2925e2049f9e7a I get a runtime of about 10 seconds, 45% of which is spent in retain/release calls according to Instruments (!!),

<    1   2   3