Encapsulating trust

[Denis Shelomovskij via Digitalmars-d]

31.08.2014 17:47, Dmitry Olshansky пишет:
> Quite recently a lot of work has been done to make most of Phobos usable
> in @safe code.
>
> While a very welcome effort, it caused a number of doubts in particular
> due to the boilerplate required to isolate a small amount of unsafe
> operations and slap "@trusted" over it.
>
> See e.g. Denis argument:
> https://github.com/D-Programming-Language/phobos/pull/2465
>
> There were proposals for language changes along the lines of having
> @trusted block alike to debug/version blocks, but nothing ever came out
> of them.
>
> Without language support I decided it worth a shot to create a universal
> wrappers to establish a consistent convention. A use of such wrapper
> should indicate that a @system function call or language feature was
> hand-verified.
>
> Names and complete set of primitives are up for debate, but here is the
> start:
>
> https://gist.github.com/DmitryOlshansky/bc02f369c8a63818bd07
>
> A bit of usage:
>
> 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);
> }
>
>
> What do you guys think?
>

The language works fine for me as it is in this aspect. E.g. functions 
from `std.file` like `read` should be marked as `@trusted` because this 
is what `@trusted` is for, a function operating unsafe stuff and 
providing a safe interface to it.

Currently the only problem is with templates like `std.array.Appender` 
when we want the compiler to infer attributes from user type and have to 
carefully wrap our code in `@trusted` blocks leaving calls to user code 
unwrapped.

Yes, my opinion here is the same as Daniel's one.


About related `std.file` pulls:

I wrote my original comment [1] to the pull because it blows the code 
size and reduce its readability by using `@trusted` nested functions 
(lambdas not used just because they currently can't be inlined, but it's 
silly as these functions work with disk and thus slow anyway).

This introduces a bad anti-pattern in the library and should be 
reverted. Just imagine a D newbie who just started leaning the language 
and is reading `std.file` module to see how easy can he use native API 
in D (e.g. I was such newbie). With all these pulls merged (current 
HEAD) he will be terrified of the code ugliness and either decide this 
is the only way to use native API in D (wrap every native function in 
`@trusted` nested function in `@safe` function) or will spend 
significant time discovering the history of this module and who is 
guilty in such bad design (e.g. I spend a lot of time when learned D 
because of `TypeTuple` used with expressions which completely confused me).


[1] 
https://github.com/D-Programming-Language/phobos/pull/2465#issuecomment-53950146

-- 
Денис В. Шеломовский
Denis V. Shelomovskij