On 2/6/15 3:02 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Friday, 6 February 2015 at 18:51:34 UTC, Steven Schveighoffer wrote:
>> I see the point now that making sure @safe functions don't have
>> escapes has the advantage of not requiring *as much* review as a
>> @system or @trusted function. I am leaning so much towards H.S. Teoh's
>> solution of making @trusted safe by default, and allowing escapes into
>> @system code. That seems like the right abstraction.
>
> Just to make sure that I got this right:
>
> I don't really understand why you need to escape to @system from
> @trusted. Isn't @trusted the same as @system but with a seal that says
> that it has been manually verified to be memory safe? @system simply
> allows the same internal semantics as @trusted but with no such declared
> guarantee to the caller?

In the proposal, @trusted code is actually considered the same as @safe, but allows @system escapes.

I don't have any time to read your further points, but I will catch up with them later, sorry!

-Steve

On 2/6/2015 5:13 AM, Vladimir Panteleev wrote:
> So, to repeat my question: which one is it? Have you changed your mind, or are
> there exceptions to the rules in the post you quoted?

It means that you, the programmer, have to decide whether it is environmental input validation or a logic error in your code.

Follow the rules:

1. exceptions are not for debugging the logic of your program
2. do not use exceptions to recover from logic bugs in your program

I have pontificated on this at GREAT length in multiple threads in this n.g. If it is still a mystery to you or anyone else, I give up. Keep in mind the levels of expertise:

newbie: follow the rules because you're told they're the right thing to do
master: follow the rules because you understand they're the right thing to do
guru: transcend the rules because you know when they don't apply

On 2/6/2015 4:17 AM, Kagamin wrote:
> On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
>> On 2/6/2015 12:31 AM, Kagamin wrote:
>>> On Thursday, 5 February 2015 at 23:39:39 UTC, Walter Bright wrote:
>>>>  static void trustedMemcopy(T[] dest, T[] src) @trusted
>>>>  {
>>>>    assert(src.length == dest.length);
>>>>    memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>>>>  }
>>>
>>> Should be enforce: assert doesn't guard against malicious usage.
>>
>> Cue my endless attempts to explain the difference between input errors and
>> logic errors :-(
>
> A little offtop: if this function is compiled in release mode and compiler
> assumes assert holds, it's free to use dest.length instead of src.length and if
> at runtime dest is longer than src, this will create heartbleed-like bug in safe
> code.

Sigh. Please visit your nearest Catholic school and ask one of the nuns to thwack your knuckles with a ruler!

On 2/6/2015 3:57 AM, Martin Krejcirik wrote:
> If I understand it correctly, Walter is against adding trusted blocks (trusted
> {...}) into @safe functions. But what about having safe blocks in @trusted
> functions ?
>
> int somefunc() @trusted
> {
>     int a = systemfunc();
>     int b;
>
>     @safe {
>        b = safefunc(); // calling systemfunc() not allowed;
>     }
>
>     return a + b;
> }

The problem is, again:

    @trusted code must have a safe interface

and with code blocks, there is no interface specified to them other than examining EVERY line of code in it.

The way interfaces are specified in D is to use functions.

On 2/6/2015 8:19 AM, John Colvin wrote:
> Is that what we want? I can't see why not, but it feels off somehow...
> Effectively you've got @trusted blocks in an @trusted function, just inverted.

Right. It just inverted the interface problem, the problem remains. So, no for this idea.

Another way to say it:

@safe => @trusted must go through a safe interface

@trusted => @safe must go through a safe interface

On 2/6/2015 10:58 AM, David Nadlinger wrote:
> @trusted doesn't differ in meaning from @safe for API clients. Both mean that
> you can call the function from @safe code, nothing more, nothing less. I hope we
> agree on that.

That is correct. @trusted is a statement about the implementation of a function, not its interface.

This suggests that @trusted should apply to blocks of code, not function declarations. Pedantically, I think that would be correct. But as we've seen in usage, this seductively makes for easy incorrect usage of @trusted. Pragmatically, the language should make it harder to write incorrect code.

Hence, I view it as the best compromise to make @trusted also apply only at the function level.

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.

But that can't work:

@trusted_is_safe {

  auto tmp = get_hardware_config();

  @system{
    mess_up_hardware_config();
  }

  // now this unsafe call is called in a @safe context, but is unsafe...
  // DMD does not catch this, so "@trusted_is_safe" is broken

  call_safe_code_that_now_is_messed_up();

  @system{
     restore_hardware_config(tmp);
  }
}

On Friday, 6 February 2015 at 21:33:01 UTC, Walter Bright wrote:
> On 2/6/2015 10:58 AM, David Nadlinger wrote:
>> @trusted doesn't differ in meaning from @safe for API clients. Both mean that
>> you can call the function from @safe code, nothing more, nothing less. I hope we
>> agree on that.
>
> That is correct. @trusted is a statement about the implementation of a function, not its interface.
>
> This suggests that @trusted should apply to blocks of code, not function declarations. Pedantically, I think that would be correct. But as we've seen in usage, this seductively makes for easy incorrect usage of @trusted. Pragmatically, the language should make it harder to write incorrect code.
>
> Hence, I view it as the best compromise to make @trusted also apply only at the function level.

Please see this post:

http://forum.dlang.org/post/riphxcqazksykafumzcg@forum.dlang.org

On 2/6/2015 11:11 AM, H. S. Teoh via Digitalmars-d wrote:
> This is precisely why I have lost all interest in @safe. It's clear that
> the present problematic situation will continue to hold, and the
> decision makers are not interested to address it. I am not going to
> waste any more time and energy on this topic.

In this thread at 8:20PM last night, Dicebot asked me:

"I am not even sure how you can show the example though, to be honest - implied
issues are about maintaining code and not just writing it."

And I replied with a specific example of how to fix one aspect of std.array. There have been no replies. What else can I do to address it?

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.