Simply, it should be replaced by:

void safeFunc() @safe {
    unsafe {
        auto vi = doUnsafeCall();
    }
}

@trusted functions are prohibited by d-idiom (so I don't know why are still in D).
So, when I need to create a simple window with OpenGL context I need to write about 10-15 calls to system functions. But D-idiom[1] for @trusted tells me to make @trusted functions as small as possible. OK, it makes sense.

but writing 20 times something like:
auto vi = (() @trusted => glXChooseXFBConfig(...))();

or:
auto vi = () @trusted { return glXChooseXFBConfig(...); }();

is annoying and just forced me to mark whole class with @trusted...



[1] https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/

On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:
> Simply, it should be replaced by:
>
> void safeFunc() @safe {
>     unsafe {
>         auto vi = doUnsafeCall();
>     }
> }
>
> @trusted functions are prohibited by d-idiom (so I don't know why are still in D).
> So, when I need to create a simple window with OpenGL context I need to write about 10-15 calls to system functions. But D-idiom[1] for @trusted tells me to make @trusted functions as small as possible. OK, it makes sense.
>
> but writing 20 times something like:
> auto vi = (() @trusted => glXChooseXFBConfig(...))();
>
> or:
> auto vi = () @trusted { return glXChooseXFBConfig(...); }();
>
> is annoying and just forced me to mark whole class with @trusted...
>
>
>
> [1] https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/
Encapsulate the function in a trusted wrapper if otfen.
Or simply not mark code that mucks with opengl as safe.
Because it is not.

On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:
> but writing 20 times something like:
> auto vi = (() @trusted => glXChooseXFBConfig(...))();

That's an anti-pattern and you should almost never actually do it. That is breaking the trusted thing, and is not what the blog means when it says keep the functions as small as possible.

> just forced me to mark whole class with @trusted...

If the class encapsulates unsafe activity into some kind of safe interface, that's what you are *supposed* to do.

On 11/25/16 5:14 AM, Satoshi wrote:
>
> void safeFunc() @safe {
>     unsafe {
>         auto vi = doUnsafeCall();
>     }
> }

How would this work for marking C functions assumed to be safe as trusted? -- Andrei

On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:
> @trusted functions are prohibited by d-idiom (so I don't know why are still in D).

Uh? No. I wonder where you've read this.

On Friday, 25 November 2016 at 15:01:43 UTC, Andrei Alexandrescu wrote:
> How would this work for marking C functions assumed to be safe as trusted? -- Andrei

You'd presumably just mark the prototypes as @safe too.

On 11/25/16 5:14 AM, Satoshi wrote:
> Simply, it should be replaced by:
>
> void safeFunc() @safe {
>     unsafe {
>         auto vi = doUnsafeCall();
>     }
> }
>
> @trusted functions are prohibited by d-idiom (so I don't know why are
> still in D).

No, they are not. @trusted escapes are for use when you can reasonably write most of the code with @safe (and get the benefits of the comipler checking safety for you). If you can't reasonably do that, you mark the whole function @trusted.

> So, when I need to create a simple window with OpenGL context I need to
> write about 10-15 calls to system functions. But D-idiom[1] for @trusted
> tells me to make @trusted functions as small as possible. OK, it makes
> sense.
>
> but writing 20 times something like:
> auto vi = (() @trusted => glXChooseXFBConfig(...))();
>
> or:
> auto vi = () @trusted { return glXChooseXFBConfig(...); }();
>
> is annoying and just forced me to mark whole class with @trusted...

Marking the whole class as @trusted is fine. "As small as possible" might mean you have to mark the whole thing as @trusted, because no code can be reasonably marked @safe.

Without seeing your function, I can't say what the best marking should be, so maybe it does make sense to add all those trusted escapes. It's also possible to simply have an inner function marked @trusted, that does the same thing, but is less verbose.

The idea behind @trusted is to mark code as "this needs to be manually checked by hand". Any time you have @safe code, but your @trusted escapes mean that the @safe code also needs to be checked, you have mismarked it.

-Steve

On 11/25/16 10:30 AM, Adam D. Ruppe wrote:
> On Friday, 25 November 2016 at 15:01:43 UTC, Andrei Alexandrescu wrote:
>> How would this work for marking C functions assumed to be safe as
>> trusted? -- Andrei
>
> You'd presumably just mark the prototypes as @safe too.

Hmmm... ok, that would work by means of the convention "@safe + no implementation really means trusted". Not too convenient I'd say. -- andrei

On Friday, 25 November 2016 at 16:03:27 UTC, Andrei Alexandrescu wrote:
> Hmmm... ok, that would work by means of the convention "@safe + no implementation really means trusted". Not too convenient I'd say. -- andrei

It works today, though. The compiler will allow you to put @safe with no body and treat it exactly as if it were @trusted.

The only difference between @safe and @trusted in this sense is the mangled name.

On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:
> but writing 20 times something like:
> auto vi = (() @trusted => glXChooseXFBConfig(...))();
>
> or:
> auto vi = () @trusted { return glXChooseXFBConfig(...); }();

Trusted blocks are used for safety inference in generic code, so that only code outside trusted blocks affects inferred safety of the generic function. Normally you should be fine by marking the trusted function with one @trusted attribute and be done with it, that's what it was designed for.

> is annoying and just forced me to mark whole class with @trusted...

And it also made code cleaner than with unsafe blocks sprinkled everywhere.