Am Wed, 15 Jan 2020 20:14:13 +0100 schrieb ag0aep6g:

> On 15.01.20 19:41, Joseph Rushton Wakeling wrote:
>> Well, apologies to Steven if I've misinterpreted his proposal. But what I had in mind was that @safe would be able to call @trusted just as it does now.
>> 
>> So, put that together with what I wrote above, and you have something that allows better validation of the internals of @trusted functions, and still gives the user clarity about which functions are safe in their own terms, and which are safe based on some programmer provided guarantees.
> 
> You're saying that an @safe function `f` is somehow more guaranteed to be safe than an @trusted function `g`, even though `f` may be calling `g`. I don't see how that makes sense.
> 
> ----
> R f(P params) @safe { return g(params); }
> R g(P params) @trusted { /* ... whatever ... */ }
> ----
> 
> Any assumptions you have about `f` better also be true about `g`.

A trusted function in D is supposed to have a safe interface: For each possible combination of argument values, a trusted function must not cause invalid memory accesses. This is the only reason you can safely call trusted functions from safe functions. It's the programmers responsibility to design trusted function APIs in a way so they can't be misused.

-- 
Johannes

On Wednesday, 15 January 2020 at 19:49:53 UTC, Joseph Rushton Wakeling wrote:
> No.  @trusted is about saying "This function should be safe to use, but that safety has been designed by the developer rather than being automatically verifiable by the compiler."

Could make sense if you only could call @trusted from @trusted... If you can call @trusted from @safe then it makes no sense whatsoever.

If you view attributes as something for external APIs then it makes no sense to distinguish between @trusted and @safe.

It is just noise that conveys nothing of substance.

On Wednesday, 15 January 2020 at 19:49:53 UTC, Joseph Rushton Wakeling wrote:
> No.  @trusted is about saying "This function should be safe to use, but that safety has been designed by the developer rather than being automatically verifiable by the compiler."
>
> Contrast with @system which can be applied to functions that are inherently not guaranteed to be safe -- e.g. where the safety (or not) depends on what input the user provides.

This is why I think it should be removed. In my world there is no "trust the human". Also @trusted in kind of backwards. It should be the caller that designate a call or operation trusted, not the the function that you call. Otherwise it is like asking car sales man if I can trust him.

On 15.01.20 22:08, Johannes Pfau wrote:
> Am Wed, 15 Jan 2020 20:14:13 +0100 schrieb ag0aep6g:
> 
>> On 15.01.20 19:41, Joseph Rushton Wakeling wrote:
[...]
>>> So, put that together with what I wrote above, and you have something
>>> that allows better validation of the internals of @trusted functions,
>>> and still gives the user clarity about which functions are safe in
>>> their own terms, and which are safe based on some programmer provided
>>> guarantees.
>>
>> You're saying that an @safe function `f` is somehow more guaranteed to
>> be safe than an @trusted function `g`, even though `f` may be calling
>> `g`. I don't see how that makes sense.
[...]
> A trusted function in D is supposed to have a safe interface: For each
> possible combination of argument values, a trusted function must not
> cause invalid memory accesses. This is the only reason you can safely
> call trusted functions from safe functions. It's the programmers
> responsibility to design trusted function APIs in a way so they can't be
> misused.

I completely agree, but I'm not sure how it's related to my rejection of Joseph's statement that @trusted "gives the user [= caller] clarity about which functions [...] are safe based on some programmer provided guarantees".

The distinction between @safe and @trusted matters when looking at the implementation of a function. It doesn't matter when calling an @safe/@trusted function, precisely because @trusted function must have safe interfaces just like @safe functions.

On Wednesday, 15 January 2020 at 21:17:38 UTC, IGotD- wrote:
> This is why I think it should be removed. In my world there is no "trust the human".

Presumably your programs are therefore self-crafted binary, since you couldn't possibly trust the humans who wrote the standard library to write valid code, or the compiler writers to translate it correctly into machine instructions? :-)

> Also @trusted in kind of backwards. It should be the caller that designate a call or operation trusted, not the the function that you call. Otherwise it is like asking car sales man if I can trust him.

I think you're getting caught up on the choice of terminology.  It's just a hierarchy of guarantees:

  @safe -- this function should behave in a memory-safe way for all possible inputs you can provide, and this can be validated by the compiler

  @trusted -- this function should behave in a memory-safe way for all possible inputs you can provide, but this has been validated by the developer, and cannot be automatically validated by the compiler

  @system -- some of the possible inputs to this function will cause it to behave in a memory-unsafe way

You don't have to like the choice of keywords, but you should recognize that they describe valuable distinctions.  There are some nice examples of how these distinctions are useful in the article linked to above.

On Wednesday, 15 January 2020 at 19:14:13 UTC, ag0aep6g wrote:
> You're saying that an @safe function `f` is somehow more guaranteed to be safe than an @trusted function `g`, even though `f` may be calling `g`. I don't see how that makes sense.

No, I'm saying that it is useful to have a clear distinction, visible in the API declaration, between functions whose promise of memory safety can be validated by the compiler, versus functions whose promise of memory safety cannot be validated by the compiler.

It's a practical distinction, because it gives the developer clarity about which parts of a codebase need to be examined in order to rule out the possibility of memory safety violations.

On Wednesday, 15 January 2020 at 23:01:57 UTC, Joseph Rushton Wakeling wrote:
>
> Presumably your programs are therefore self-crafted binary, since you couldn't possibly trust the humans who wrote the standard library to write valid code, or the compiler writers to translate it correctly into machine instructions? :-)
>

@safe is a subset of D that guarantees no memory corruption. The only way to ensure this is if the compiler have all the source code (will object code also work?) and can check that all the calls are also @safe. If this condition is not met, it is not safe by definition. @trusted code has reduced memory guarantees and can also call unsafe code further along the line and therefore unsafe.

@trusted is therefore impossible and the criteria cannot be met. It's just a badge meaning nothing.

> I think you're getting caught up on the choice of terminology.  It's just a hierarchy of guarantees:

No, I'm caught up in the semantics. I see that a condition cannot be met and therefore unnecessary. @trusted is an oxymoron.

On Wed, Jan 15, 2020 at 11:01:57PM +0000, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On Wednesday, 15 January 2020 at 21:17:38 UTC, IGotD- wrote:
> > This is why I think it should be removed. In my world there is no "trust the human".
> 
> Presumably your programs are therefore self-crafted binary, since you couldn't possibly trust the humans who wrote the standard library to write valid code, or the compiler writers to translate it correctly into machine instructions? :-)
[...]

And you also built your own hardware, because you cannot trust the hardware manufacturers that they didn't have a bug in silicon that causes memory corruption under rare circumstances, in spite of your correctly-coded instructions. Or they didn't put a trapdoor in silicon that allows unknown 3rd parties from some remote server to gain ring 0 access to your CPU.


T

-- 
My program has no bugs! Only undocumented features...

On Wednesday, 15 January 2020 at 23:16:21 UTC, Joseph Rushton Wakeling wrote:
> No, I'm saying that it is useful to have a clear distinction, visible in the API declaration, between functions whose promise of memory safety can be validated by the compiler, versus functions whose promise of memory safety cannot be validated by the compiler.

You're saying that it is useful for me as a user of Phobos when I see that, for example, std.stdio.File.open is @trusted [1], right?

I disagree. It doesn't mean anything other than @safe in that context. Knowing that the function is @trusted instead of @safe is of zero use to a user of Phobos. It cannot help them make any decision whatsoever.

> It's a practical distinction, because it gives the developer clarity about which parts of a codebase need to be examined in order to rule out the possibility of memory safety violations.

I.e., it's a tool for library authors, not for library users. You clearly spoke of an "external" or "outside" user of the function before.


[1] https://dlang.org/phobos/std_stdio.html#.File.open

On Wednesday, 15 January 2020 at 23:26:01 UTC, H. S. Teoh wrote:
> And you also built your own hardware, because you cannot trust the hardware manufacturers that they didn't have a bug in silicon that causes memory corruption under rare circumstances, in spite of your correctly-coded instructions. Or they didn't put a trapdoor in silicon that allows unknown 3rd parties from some remote server to gain ring 0 access to your CPU.

To be honest, I just use butterflies :-)