"Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com> wrote:
> On Friday, 6 February 2015 at 13:28:59 UTC, Steven Schveighoffer wrote:
>> The bottom line of my reasoning is that code changes over time, > by different people. Context is forgotten. It's much better to > have the compiler verify you know what you are doing when > working with @trusted than it is to just allow anyone to inject > code anywhere.
> 
> Actually, I think this argument goes against what you are arguing for. Anything within a @trusted section has a big warning sign attached to it that says "cannot modify this without detailed review". But the compiler cannot verify that a @safe function with local @trusted blocks are actually safe, so it only buys you a false sense of security.

I'd go even further:
The compiler could even make optimizations in @safe code based on the
assumption that all @trusted function calls expose a safe interface. I
suspect this will lead to undefined behavior and very subtle bugs.

On 2/6/15 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 ?

That would be sensible - perhaps the best step forward following this long discussion. -- Andrei

On 2/6/15 5:13 AM, Vladimir Panteleev wrote:
> On Friday, 6 February 2015 at 10:28:38 UTC, Walter Bright wrote:
>> On 2/6/2015 1:01 AM, Vladimir Panteleev wrote:
>>> On Friday, 6 February 2015 at 08:58:05 UTC, Walter Bright wrote:
>>>> Cue my endless attempts to explain the difference between input
>>>> errors and
>>>> logic errors :-(
>>>
>>> So which one is it?
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/Program_logic_bugs_vs_input_environmental_errors_244143.html
>>
>
> That doesn't answer my question.
>
> A few years ago, I recall, you were arguing that for functions which are
> or may be exported to a DLL, thus all Phobos functions, it is impossible
> to predict how the functions will be used. Thus, you argued, the
> functions' input has to be validated, even if invalid parameters can
> only be passed to the function as a result of a program bug, and never
> user input.
>
> 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?

Could you all please grant me this wish - let's not get into that vortex again? It renders everyone involved unproductive for days on end. Thanks. -- Andrei

On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu wrote:
> On 2/6/15 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 ?
>
> That would be sensible - perhaps the best step forward following this long discussion. -- Andrei

It feels inelegant, but it might be the best way out of a bad situation.

I can instantly see this happening:

void foo() @trusted
{
    @safe
    {
        //loads of code
    }

    //a few lines of system code, only safe due to context in the @safe blocks

    @safe
    {
        \\loads of code
    }
}

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.

On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
> I can instantly see this happening:
>
> void foo() @trusted
> {

       auto p = malloc(…)

>     @safe
>     {
            global_datastructure.push(p)
>         //loads of code
>     }
>
       free(p)

>     //a few lines of system code, only safe due to context in the @safe blocks
>
>     @safe
>     {
>         \\loads of code
>     }
> }
>
> Is that what we want?

Nope.

On 2/6/15 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.

That's the natural direction - the default assumption is weak, and you have the option to temporarily strengthen it. That said I'm not jazzed about the whole thing. What we have is the right balance. -- Andrei

On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
> It feels inelegant, but it might be the best way out of a bad situation.
>
> I can instantly see this happening:
>
> void foo() @trusted
> {
>     @safe
>     {
>         //loads of code
>     }
>
>     //a few lines of system code, only safe due to context in the @safe blocks
>
>     @safe
>     {
>         \\loads of code
>     }
> }
>
> 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.

Some observations.

1. You cannot corrupt memory in the first @safe block. That's a plus.
2. It solves the "my-@safe-function-turned-@system-behind-my-back"-problem
3. It solves the problems the current @trusted-abuse in std.file tried to solve

And most importantly:
If that function can be made @trusted, there probably is a function bar, so that

void bar() { .. } @trusted

void foo() @safe
{

   @safe {}
   bar();
   @safe {}
}

On Friday, 6 February 2015 at 16:11:31 UTC, Andrei Alexandrescu wrote:
> On 2/6/15 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 ?
>
> That would be sensible - perhaps the best step forward following this long discussion. -- Andrei

This still does not solve the template inference problem though, unless you make it a "non-@trusted" block instead of requiring @safe-ty. And then you'd end up with the—at least to my eyes—rather absurd situation that a template function that is marked @trusted might actually end up being @system.

David

On Friday, 6 February 2015 at 16:40:10 UTC, David Nadlinger wrote:
>
> This still does not solve the template inference problem though, unless you make it a "non-@trusted" block instead of requiring @safe-ty.

Don't understand. If that matters, the code shouldn't be marked @trusted
in the first place.

> And then you'd end up with the—at least to my eyes—rather absurd situation that a template function that is marked @trusted might actually end up being @system.
>
> David

How?

On Friday, 6 February 2015 at 15:48:45 UTC, Ola Fosheim Grøstad wrote:
>
> 2. @trusted sections are written without dependencies
>
This really won't happen unless statically enforced because humans are involved.

> 3. @trusted are formally proven safe
>
...by humans?

> 4. @trusted functions rarely change
>
Is this so?  Data, please.

> 5. @trusted is 0-2% of the codebase
>
In Phobos, you mean?  You've checked?

2% in my world is already thousands of lines of code, and I'm far from having the largest of maintenance burdens.  Get it to a small fraction of a percent and then maybe we can talk.

> linear type system
>
Time and place, man.  I'm not even sure why you're bringing this up here.

> Jonathan recently said he would like to volunteer some, and he has mentioned a background with math/proofs. If he is willing to do safety review, then so I am, then so will someone else who feel like refreshing their training in program verification... Use the resources you have. Those resources, we do have, I think. Unused.
>
That's great; thanks for that.  Seriously.  But to my mind, that adds a whole new stack of concerns.  How many people do you think you'll need to absorb the patch flow to Phobos?  In perpetuity?  How do you separate the qualified from the overconfident?  How many people need to check something independently before you're reasonably certain there are no mistakes?  etc.  Any time you bind yourself to human process, you've created a bottleneck of uncertainty.

And that's just Phobos! You don't scale horizontally and it's kind of problematic to approach this with the assumption that everyone wanting to write something that even reasonably approximates safe code is a mathematician.  Rather, that doesn't bear out in practice at all.

Bottom Line: If it can't be even partially automated, it's not useful.

-Wyatt