On Friday, 6 February 2015 at 17:02:44 UTC, Wyatt wrote:
> 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?
>

At least I expect the amount of @trusted in phobos to be much higher than in normal user code.

On Friday, 6 February 2015 at 16:50:51 UTC, Tobias Pankrath wrote:
> 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.

Let's say you have a template function that accepts a range. For performance, you want to do some of the processing in a way that is @system, but can be verified to be correct for all inputs in this specific case. In other words, that piece of code can be rightfully @trusted. However, marking the whole function as @trusted would be a mistake, as the primitives of the range that is your input data might be @system.

Using @trusted blocks (which is what is currently emulated by the nested functions/lambdas), you can just mark your unsafe code as @trusted and let the compiler figure out the safety of the whole function. @safe blocks wouldn't work for this, as you'd inadvertently require the user-supplied input range to have @safe/@trusted primitives.

>> 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?

I was referring to a hypothetical "untrusted" block that might be used something like this:

---
void foo(Range)(Range r) @trusted {
  // ...

  untrusted {
    r.front;
  }

  // Your manually checked code.

  untrusted {
    r.popFront;
  }

  // …
}
---

This seems incredibly backwards. Not only is it confusing to read, it also encourages bugs where operations mistakenly end up being @trusted by forgetting to mark, say, an added call to r.empty as untrusted. On the other hand, it is much more unlikely that you accidentally add a new @trusted block. It seems obvious that explicitly whitelisting a small number of potentially dangerous but safe operations is much less error-prone approach than disabling compiler checks for everything and then having to remember to blacklist all unverified external dependencies.

David

On Friday, 6 February 2015 at 16:19:26 UTC, John Colvin wrote:
> 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.

It's been suggested that '@system' be used to mark the blocks in question. The point would be to emphasize the dangerousness of the operation. The function is still @trusted, but inside, the @system code is marked as such.

On 2/6/15 8:40 AM, David Nadlinger wrote:
> 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

What is that?

> 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.

@trusted functions are @system.


Andrei

On 2/6/15 9:07 AM, Tobias Pankrath wrote:
> At least I expect the amount of @trusted in phobos to be much higher
> than in normal user code.

Exactly. There's a bunch of low-level interfaces in Phobos and also some code that aims at maximum efficiency.

Andrei

On Friday, 6 February 2015 at 17:12:40 UTC, David Nadlinger wrote:
> Let's say you have a template function that accepts a range. For performance, you want to do some of the processing in a way that is @system, but can be verified to be correct for all inputs in this specific case. In other words, that piece of code can be rightfully @trusted. However, marking the whole function as @trusted would be a mistake, as the primitives of the range that is your input data might be @system.
>
> Using @trusted blocks (which is what is currently emulated by the nested functions/lambdas), you can just mark your unsafe code as @trusted and let the compiler figure out the safety of the whole function. @safe blocks wouldn't work for this, as you'd inadvertently require the user-supplied input range to have @safe/@trusted primitives.

I'm trying to promote suggesting '@system' blocks instead of '@trusted'. '@trusted' functions, but '@system' blocks - which can only go in @trusted functions (@system block in @system functions are redundant). It's the same semantics, but it might win the day because the intent is to isolate the @system code, while still presenting a @trusted interface, as seems so important to the leadership.

On Friday, 6 February 2015 at 17:16:19 UTC, Andrei Alexandrescu wrote:
> On 2/6/15 8:40 AM, David Nadlinger wrote:
>> This still does not solve the template inference problem
>
> What is that?

See my reply to Tobias [1]. This seems to be the crux of our disagreement and/or misunderstanding, and is precisely the reason why I recommended you to try your hand at rewriting some of the std.array range algorithms yourself in the Bugzilla discussion. Let me know if the explanation in said post is not clear enough.

>> 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.
>
> @trusted functions are @system.

I meant "@system" as in the part of the function type/API contract, not concerning the implementation. That is, a template function that is marked @trusted might not be able to be called from @safe code.

David


[1] http://forum.dlang.org/post/fwiivepmjfvqbxgagcrm@forum.dlang.org

On Friday, 6 February 2015 at 17:02:44 UTC, Wyatt wrote:
>> 3. @trusted are formally proven safe
>>
> ...by humans?

It isn't that hard for typical library code that is required to be non-safe.

You don't have to do better than the compiler code in terms of probability of slipping things through... :-P

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

That would be a requirement. That means you should have high requirements for design before allowing implementation of @trusted.

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

That would be a requirement. If you have lots of @trusted, then there is something wrong with the abstraction level @trusted is used at (or the compiler features).

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

What is your alternative? You need to point at the alternative. The only alternative I see is to drop @safe or keep @trusted or change the type system.

> 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?

One semi-formal proof written down. 3 qualified (education) independent reviews of the proof.

What makes this more difficult for the standard library than for the compiler internals?

> etc.  Any time you bind yourself to human process, you've created a bottleneck of uncertainty.

And the alternative is?

> 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.

Then drop @safe...

> I'm trying to promote suggesting '@system' blocks instead of '@trusted'. '@trusted' functions, but '@system' blocks - which can only go in @trusted functions (@system block in @system functions are redundant). It's the same semantics, but it might win the day because the intent is to isolate the @system code, while still presenting a @trusted interface, as seems so important to the leadership.

That might be better than using @safe inside @trusted:

@trusted void myfunc() {
//implicitly safe
...
@system { //wouldn't compile otherwise.
   auto ptr = cast(ubyte*)4;
}

//implicitly safe again
}

On Friday, 6 February 2015 at 16:19:00 UTC, Andrei Alexandrescu wrote:
> On 2/6/15 5:13 AM, Vladimir Panteleev wrote:
>> 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

What is the problem? Sorry if my post sounded confrontational, but I wasn't going to argue - I just want to understand the language designers' current position on this topic.