DIP1028 - Rationale for accepting as is

[Petar]

On Monday, 25 May 2020 at 12:41:01 UTC, Paul Backus wrote:
> On Monday, 25 May 2020 at 12:30:11 UTC, Zoadian wrote:
>> On Monday, 25 May 2020 at 10:41:43 UTC, rikki cattermole wrote:
>>> It is meant to mean that at some point it has been 
>>> mechanically checked by the compiler.
>>>
>>> Either during current compilation or a prior one.
>>>
>>> Which means it has to be valid on function declarations 
>>> without bodies so i.e. .di file generation works correctly 
>>> which is just a generated D file, nothing special syntax of 
>>> semantics wise.
>>
>> .di files _could_ just use @trusted instead of @safe. but for 
>> extern(D) we could at least add it to the name mangling. it's 
>> still not 100% safe, but at least you'd have to work hard to 
>> get it wrong.
>
> It's been proposed before that @safe and @trusted should have 
> the same mangling, since there's no difference between them 
> from the calling code's perspective.

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 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).

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 
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.