DIP1028 - Rationale for accepting as is

[Petar]

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"- at safe today and even if there

That said, there is no "strong- at 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.