> 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 have to use a makefile (or u
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 af
> 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 problem:
>
> - when you re
> 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 compiler does not see #defines
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 som
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 appropr