Re: [swift-evolution] [SPM] Roadmap?

> On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution > wrote: > > It’d be great to be able to stick an #include path and a linker flag string > into Package.swift instead of creating empty c modules that just include > system headers. right now this means you

[swift-evolution] Zero-copy String buffer access

One of Swift’s major advantages as a language is the ease of bridging from Swift code to C. This ease makes it possible to utilise the vast body of existing code to bootstrap projects, rather than reinventing the world in Swift every time we have a problem. The String type in Swift has some

Re: [swift-evolution] Opaque Pointers in Swift

> On 24 Oct 2017, at 18:23, Johannes Weiß wrote: > > How do people think about this proposed change? I think keeping type information on OpaquePointer would be extremely useful, and definitely improves some of the sharp edges of that type. > this should solve your

Re: [swift-evolution] Opaque Pointers in Swift

> On 24 Oct 2017, at 18:11, Félix Cloutier wrote: > > Could you do a conditional typealias? I don’t *think* so. In the case of OpenSSL the #define you want to use is OPENSSL_VERSION_NUMBER, which is defined in an OpenSSL header file. As far as I know, the Swift

[swift-evolution] Opaque Pointers in Swift

I wanted to discuss a recent difficulty I’ve encountered while writing a Swift program that uses a C library that has recently changed its API to use opaque pointers, with an eye towards asking whether there are suggestions for ways to tackle the problem that I haven’t considered, or whether

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

I strongly recommend building the padded room. Average to good engineers (which I assume is intended to be a proxy for “engineers who know about CSPRNGs and have considered their personal threat model”) know enough to work out what kind of RNG they have available and to use the one most