On 2/6/2015 5:28 AM, Steven Schveighoffer wrote:
> It's better because I know where it is used. It's used in one place, and I can
> squash it right there saying "No, you can't do this in this one place." Instead
> of reviewing an API in ALL POSSBILE CONTEXTS (which if trustedCast is a public
> API, would be a lot), I have to review one call in ONE CONTEXT.
>
> The former is WORSE because it can be used in 100 places. Now I have to go
> through and fix ALL THOSE FUNCTIONS that use it, because its interface was
> exposed to the whole of phobos.

This is the crux of the problem - failing to define a safe interface to the trusted code block. Without defining an interface, you're right, you must review all the context(s) that call it. With a safe interface you DO NOT. You only have to review the interface.

A simple rule:

"If you need to do a safety review on the context in which @trusted code is called YOU ARE DOING IT WRONG because you've failed to provide a safe interface to the @trusted code."


It's like solving a physics problem and winding up with negative energy. If that happens, you made a mistake. It is not a matter of judgement or opinion, it is an objective fact.

Going forward, all @trusted code that leaks unsafety into its context will be rejected for inclusion in Phobos. The code reviewer only has to review the @trusted block to determine this - he does not have to review the context.

On Friday, 6 February 2015 at 20:13:18 UTC, Steven Schveighoffer wrote:
> In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes.

That seems like a good idea and in the spirit of what the goal is. However, won't it be a breaking change?

On 2/6/2015 7:14 AM, Wyatt wrote:
> The current @trusted semantics (and accompanying politics) make it exceedingly
> clear that @safe is meaningless for anything beyond trivial, one-off tools that
> will never receive maintenance.

You are correct in how @trusted is currently (mis)used in Phobos. We aim to fix this.

@trusted must provide a safe interface. No exceptions. Yes, that requires review of @trusted code by someone who thoroughly understands this, but there's no other way.

On 2/6/2015 7:48 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Then how is this more work than implementing something like a linear type system
> that is both tedious for the programmer and has taken Rust 8 years to get into
> working shape...?

Rust has "unsafe" blocks with specific instructions that it cannot be verified mechanically and it is up to the programmer to ensure a safe interface to it.

So no, Rust didn't get that working, either, and it is far beyond current compiler technology to do it.

On Friday, 6 February 2015 at 22:24:48 UTC, Walter Bright wrote:
> Rust has "unsafe" blocks with specific instructions that it cannot be verified mechanically and it is up to the programmer to ensure a safe interface to it.
>
> So no, Rust didn't get that working, either, and it is far beyond current compiler technology to do it.

Rust guarantees, though, that all code outside of unsafe blocks/functions is completely safe, which D doesn't do because of trusted. I think that `unsafe` in Rust is more like @trust in D, but I'm not completely sure about that.

On 2/6/2015 2:39 PM, Meta wrote:
> On Friday, 6 February 2015 at 22:24:48 UTC, Walter Bright wrote:
>> Rust has "unsafe" blocks with specific instructions that it cannot be verified
>> mechanically and it is up to the programmer to ensure a safe interface to it.
>>
>> So no, Rust didn't get that working, either, and it is far beyond current
>> compiler technology to do it.
>
> Rust guarantees, though, that all code outside of unsafe blocks/functions is
> completely safe, which D doesn't do because of trusted. I think that `unsafe` in
> Rust is more like @trust in D, but I'm not completely sure about that.

Rust guarantees no such thing, because it is explicitly up to the Rust programmer to verify a safe interface to unsafe code blocks.

It is no different from the D @trusted programmer verifying a safe interface to @trusted code.

On Friday, 6 February 2015 at 21:56:40 UTC, Walter Bright wrote:
> On 2/6/2015 11:29 AM, Zach the Mystic wrote:
>> My attitude is not based on evidence. It's based on just thinking about the
>> problem:
>>
>> http://forum.dlang.org/post/eeglnychgudcffpjcdvy@forum.dlang.org
>>
>> I really can't answer this question.
>
> You asked:
>
> "Why not force the programmer to tag precisely those portions of his code
> which cause him to tag his function @trusted to begin with?"
>
> That question has been asked and answered repeatedly. The answer is that @trusted is not only to TAG unsafe code, but must provide a SAFE INTERFACE to it.
>
>    @trusted {
>       ... unsafe code ...
>    }
>
> provides no indication of what the interface to the unsafe code is. Addressing only the TAG aspect is insufficient.

No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions.

This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on!

On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:
> No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions.

Also, to be clear, any @system block inside a @safe function is an automatic error.

On Friday, 6 February 2015 at 23:02:54 UTC, Zach the Mystic wrote:

> No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've moved beyond requesting @trusted blocks. We are no longer requesting them. We are requesting *@system* blocks, which can only appear in @trusted and @system functions. Any unsafe code appearing in a @trusted function which is not inside a @system block is an error. We've changed the name, but I think it will make a world of difference regarding how you will look at it. Marking '@system' code inside a @trusted function is exactly what is requested. Your message about '@trusted' being only acceptable as an interface has been heard. There will be no @trusted blocks, only @system blocks, which are the exact same thing, except they can only appear in @trusted and @system functions.
>
> This solution appeals to me greatly. It pinpoints precisely where unsafe code can generate; it catches unintended safety violations in all @trusted code outside @system blocks, as requested by many people so far; it makes systems programming highly visible, with redundancy at the function signature and at the unsafe code itself. I really think it's spot on!

this sounds interesting, is anyone going to make a DIP for it?

On 2/6/2015 3:02 PM, Zach the Mystic wrote:
> No, at least three of us, Steven, H.S. Teoh and myself have confirmed that we've
> moved beyond requesting @trusted blocks. We are no longer requesting them. We
> are requesting *@system* blocks, which can only appear in @trusted and @system
> functions. Any unsafe code appearing in a @trusted function which is not inside
> a @system block is an error. We've changed the name, but I think it will make a
> world of difference regarding how you will look at it. Marking '@system' code
> inside a @trusted function is exactly what is requested. Your message about
> '@trusted' being only acceptable as an interface has been heard. There will be
> no @trusted blocks, only @system blocks, which are the exact same thing, except
> they can only appear in @trusted and @system functions.
>
> This solution appeals to me greatly. It pinpoints precisely where unsafe code
> can generate; it catches unintended safety violations in all @trusted code
> outside @system blocks, as requested by many people so far; it makes systems
> programming highly visible, with redundancy at the function signature and at the
> unsafe code itself. I really think it's spot on!

I suspect that such a feature would simply lull people into a false sense of security in that merely tagging an unsafe cast with @system and the compiler accepting it is good enough.

My evidence for this is how @trusted was used in Phobos.