On 2/9/15 10:13 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Monday, 9 February 2015 at 14:40:36 UTC, Steven Schveighoffer wrote:
>> On 2/7/15 7:11 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>
>>> You are trying to do this:
>>>
>>> 1. mechanically verify the whole @trusted region
>>>
>>> 2. manually verify the whole @trusted region, but be sloppy about it
>>> here an there
>>>
>>> 3. Ooops, we were sloppy in the wrong spot...
>>
>> No.
>>
>> A @trusted function is manually verified, period.
>>
>> But we also must tag potential points of leakage with @system. In
>> fact, it probably could be a warning/error if you have a @trusted
>> function without any @system escapes (it could just be marked @safe).
>
> That's a nice migration path, btw. First, warn about @trusted functions
> without @system blocks and don't enforce @safe-ty inside them, later
> disallow them and do enforce @safe-ty in the others.

Yes, that solves the problem of breaking code with this... Nice idea.

-Steve

On 2/6/15 7:29 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Feb 06, 2015 at 04:04:48PM -0800, Walter Bright via Digitalmars-d wrote:
> [...]
>> I agree with Andrei in that I do not believe that reviewing a @trusted
>> function, line by line, for safety is necessarily some sort of
>> maintenance nightmare. If it is, then a refactoring should be
>> considered to encapsulate the unsafe code in a smaller, simpler
>> manner.
> [...]
>
> This does not take into the account the fact that a @trusted function
> may call other, non-@trusted, functions. When one of those other
> functions changes, the @trusted function necessarily needs to be
> reviewed again.

This problem isn't solved by the proposal, however. If you are calling a @system function inside a @trusted function, and you've marked it as @system, then changing the @system function does not affect the call.

However, if you changed a @safe function into a @system function, then a call inside a @trusted function would have to now be annotated.

It's important to note that our proposal will not fix cases where something subtle happens inside a @system block. What it DOES do is limit this effect to the @system block instead of the whole function.

-Steve

On 2/6/15 4:48 PM, Walter Bright wrote:
> 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?
>

In the case you bring up, maintenance is easy -- the code is incorrect, it needs to be fixed/rewritten. No solution ever implemented or proposed can stop this from happening.

The case being discussed by Dicebot, and most of us, involves a case where an entire @trusted function is PROPERLY implemented, yet someone adds incorrect code to it. The compiler does not complain.

Note that if the requested solution was implemented, each of these calls should be individual cases to inspect. I don't think anyone disagrees that uninitializedArray shouldn't be a public @trusted function. But individual cases of it CAN be properly safe.

-Steve

On Monday, 9 February 2015 at 14:40:36 UTC, Steven Schveighoffer wrote:
> But we also must tag potential points of leakage with @system. In fact, it probably could be a warning/error if you have a @trusted function without any @system escapes (it could just be marked @safe).
>
> Think of it this way: the @system tags are the only places where issues can creep into the function. But then you have to apply the leaks to the whole function. It makes the problem of finding potential safety issues more tractable, because the compiler forces us to identify the root causes.

The compiler should only verify what is needed for the type system to work. There is no need to differentiate between @trusted and @system for that.

If you require using "@system" for annotation, then you will have to change the language every time you improve the verifier. Because this ad hoc annotation will be unsuitable for a more powerful verifier.

And it isn't obvious that treating @trusted as @safe will not lead to false positives.