On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov [ZombineDev]
wrote:
It may be true (of course modulo meta-programming) that it
doesn't make a difference for the calling code, but I
personally want have the guarantees that a function that I'm
doesn't make a difference for the calling code, but personally
I want [to] have the guarantees that a function that I'm
calling is truly @safe (it doesn't contain or call any @trusted
code, transitively, nor it calls any @safe code, which access
global variables initialized by @system static/module
constructors).
This is very far from a rigorous definition of "strong @safe-ty"
- but I hope it's just enough for the casual reader to understand
my intention.
In my line work (blockchain smart contracts) some of the ways
of how this is typically achieved include:
* having a very minimal smart contract code size
* having either no third-party dependencies or using one or two
which are open-source and more importantly verified by multiple
teams and having very high reputation
* extensive code auditing by third-party teams. Depending on
the circumstances, we may end up paying more for the auditing
of the code, than the actual development.
That said, there is no "strong"-@safe today and even if there
That said, there is no "strong-@safe" [in D] today and even if
there
was, it would account for a tiny subset of all attack vectors
that I have to care about (basically all possible logical bugs
allowed in type-safe and memory-safe code), but I'm not sure
how erasing the difference between @safe and @trusted on the
interface level would help.
