I didn't know the spec was changed to include a section on
@safe/@trusted/@system interfaces, because otherwise I wouldn't
have made this thread. But regardless, thank you everyone for
your time: your posts are very helpful.
On 5/28/20 8:09 PM, Clarice wrote:
It seems that @safe will be de jure, whether by the current state of
DIP1028 or otherwise. However, I'm unsure how to responsibly determine
whether a FFI may be @trusted: the type signature and the body. Should I
run, for example, a C library through valgrind
On 29.05.20 08:28, JN wrote:
Alternatively you could just use @trusted blocks. Unsafe blocks are a
common practice in languages like C# or Rust when it comes to calling
unsafe code. @safe isn't about 100% bulletproof safety. @safe is (should
be) about not having memory related errors outside of
On 29.05.20 02:09, Clarice wrote:
It seems that @safe will be de jure, whether by the current state of
DIP1028 or otherwise. However, I'm unsure how to responsibly determine
whether a FFI may be @trusted: the type signature and the body. Should I
run, for example, a C library through valgrind t
On Friday, 29 May 2020 at 00:09:56 UTC, Clarice wrote:
It seems that @safe will be de jure, whether by the current
state of DIP1028 or otherwise. However, I'm unsure how to
responsibly determine whether a FFI may be @trusted: the type
signature and the body. Should I run, for example, a C libra
On Friday, 29 May 2020 at 00:09:56 UTC, Clarice wrote:
It seems that @safe will be de jure, whether by the current
state of DIP1028 or otherwise. However, I'm unsure how to
responsibly determine whether a FFI may be @trusted: the type
signature and the body. Should I run, for example, a C libra
It seems that @safe will be de jure, whether by the current state
of DIP1028 or otherwise. However, I'm unsure how to responsibly
determine whether a FFI may be @trusted: the type signature and
the body. Should I run, for example, a C library through valgrind
to observe any memory leaks/corrupt
