Encapsulating trust

[Dmitry Olshansky via Digitalmars-d]

02-Sep-2014 04:03, Walter Bright пишет:
> On 8/31/2014 6:47 AM, Dmitry Olshansky wrote:
>> import core.stdc.string;
>> import trusted;
>>
>> void main() @safe
>> {
>>
>>      char[] msg = "Hello!".dup;
>>      char[] msg2 = msg;
>>      import trusted; // may also use static import for absolute clarity
>>      assert(call!memcmp(addrOf(msg[0]), addrOf(msg2[0]), msg.length)
>> == 0);
>> }
>
> I don't agree with the notion of having primitives that provide escapes
> from @safe - it means the interleaving of @safe and @system code becomes
> too easy, and too easy to miss.
>

Make distinctive name like assumeSafe and it's going to be trivially 
grepable.

> I also don't agree with the notion of having @trusted blocks of the form:
>
>      @trusted {
>          ... system code ...
>      }

>
> We already have a mechanism to do that - @trusted nested functions. The
> code example becomes:

So there is need, but somehow requires a bunch of useless boilerplate, 
like repeating arguments and inventing creative names for local functions.
>
>    void main() @safe {
>       char[] msg = "Hello!".dup;
>       char[] msg2 = msg;
>
>       void checkEquals(const char[] msg, const char[] msg2) pure @trusted {
>         assert(msg.length == msg2.length);
>         assert(memcmp(msg.ptr, msg2.ptr, msg.length) == 0);
>       }
>

So you think adding boilerplate will make function more easily 
verifiable? Time and statistics proven that more LOCs ==> more bugs. 
Especially highly repetitive patterns, because nobody actually reads them.



-- 
Dmitry Olshansky