On 2/5/2015 12:25 PM, Steven Schveighoffer wrote:
> On 2/5/15 3:13 PM, Walter Bright wrote:
>> So the question is, what does @trusted actually buy you, since the
>> compiler can't check it?
>>
>> It serves as notice that "This function merits special attention during
>> code review to check that it has a safe interface and that its
>> implementation is correct."
>>
>
> That also applies to @safe functions since they can call @trusted functions.

No - the @trusted function is reviewed to ensure it has a safe interface. Then there is no need to review for safety anyone that calls it. It's the whole point.

For example, https://issues.dlang.org/show_bug.cgi?id=14127

A rather cursory inspection reveals that these @trusted functions have unsafe interfaces, and are therefore unacceptable in Phobos. (Of course, D will let you write such code because it is a systems programming language, but Phobos must be an example of best practices, and these are not.)


> In essense, @trusted buys you headaches. I think we should try to lessen them.

An aspect of a well-designed encapsulation is the number of @trusted interfaces is minimized. If you find an abstraction that has @trusted sprinkled liberally through it, it's an indicator of a failed abstraction.

On Thursday, 5 February 2015 at 20:13:32 UTC, Walter Bright wrote:
> On 2/5/2015 11:49 AM, Andrei Alexandrescu wrote:
>> As much as I was shocked about the use of @trusted/@safe/@system in std.file,
>> std.array and sadly possibly in other places, I found no evidence that the
>> feature is misdesigned. I continue to consider it a simple, sound, and very
>> effective method of building and interfacing robust code. An excellent
>> engineering solution that offers a lot of power at a modest cost.
>>
>> I do not support this proposal to change the semantics of
>> @trusted/@safe/@system.
>
> I agree.
>
> So the question is, what does @trusted actually buy you, since the compiler can't check it?
>
> It serves as notice that "This function merits special attention during code review to check that it has a safe interface and that its implementation is correct."

Couldn't you just use a comment?

On Thu, Feb 05, 2015 at 03:39:16PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> I think the *fundamental* problem with @trusted (currently) is that it assumes all the code it covers was written simultaneously and is not allowed to morph. This isn't the way code is written, it's massaged and tweaked over long periods of time by different people.

Thank you, that's exactly what I've been trying to say, but rather poorly. This is what makes the current incarnation of @trusted unworkable in real-life. Putting it on a function is a stamp of approval that the code has been verified by a human. Unfortunately, the element of time has been neglected. It may have been verified back when it was first committed, but now that 10 other people have stuck their grubby hands into the code, who knows if the original verification still applies? Yet the @trusted label continues to be a stamp of approval claiming that the function is still safe. It's like a car insurance sticker without expiry date. The insurance company may have gone bust for all I know, but it sure looks good that my car is still "insured"!

There needs to be some kind of "change insurance" to @trusted. If somebody makes a careless code change that may break the promise of @trusted, there needs to be a way for the compiler to detect this and complain loudly. Of course, we can't prevent *malicious* changes, since there's always another way to work around the compiler, but in the reasonable cases at the very least, careless mistakes ought to be caught and pointed out. Such as a @safe helper function used by a @trusted function becoming @system because somebody modified the original implementation. Requiring some kind of annotation on exactly what parts of a @trusted function rely on unsafe (or rather, safe but unverifiable by the compiler) operations helps by introducing a barrier for mistakes: the compiler will reject your code unless you consciously mark it up as trusted (thereby indicating that you have manually verified the code -- or maliciously introducing unsafe code in @trusted, as the case may be).


T

-- 
Computers shouldn't beep through the keyhole.

On 2/5/15 3:54 PM, Walter Bright wrote:
> On 2/5/2015 12:25 PM, Steven Schveighoffer wrote:
>> On 2/5/15 3:13 PM, Walter Bright wrote:
>>> So the question is, what does @trusted actually buy you, since the
>>> compiler can't check it?
>>>
>>> It serves as notice that "This function merits special attention during
>>> code review to check that it has a safe interface and that its
>>> implementation is correct."
>>>
>>
>> That also applies to @safe functions since they can call @trusted
>> functions.
>
> No - the @trusted function is reviewed to ensure it has a safe
> interface. Then there is no need to review for safety anyone that calls
> it. It's the whole point.

So you're saying that @safe is mechanically verified as long as @trusted functions are manually reviewed. It's that manually reviewed part that I think we have an issue with. And there is definitely a feel of "I can use trusted because I know I will only call it this way" without considering future possible calls.

I fully expect we can devise rules to make sure @trusted memory details do not leak out of the functions in an unsafe way (and have a much better, @safer code base). But it would be nice if the compiler helped enforce them.

>> In essense, @trusted buys you headaches. I think we should try to
>> lessen them.
>
> An aspect of a well-designed encapsulation is the number of @trusted
> interfaces is minimized. If you find an abstraction that has @trusted
> sprinkled liberally through it, it's an indicator of a failed abstraction.
>

I think you just made this up :)

But I agree that @trusted should be used sparingly not liberally. The problem is that when faced with such a huge function that calls one non-@safe one, marking the whole thing as @trusted disables all the mechanical verification for everything.

There has to be a better way.

-Steve

On 2/5/15 12:24 PM, Zach the Mystic wrote:
> At minimum, there needs to be official documented guidance on how to use
> @trusted. If phobos developers got this far without knowing how to use
> it (assuming their complaints on its design are indeed meritless), how
> can anyone else be expected to?

Yah, some documentation is needed. -- Andrei

On Thursday, 5 February 2015 at 21:15:52 UTC, Steven Schveighoffer wrote:
>> An aspect of a well-designed encapsulation is the number of @trusted
>> interfaces is minimized. If you find an abstraction that has @trusted
>> sprinkled liberally through it, it's an indicator of a failed abstraction.
>>
>
> I think you just made this up :)
>
> But I agree that @trusted should be used sparingly not liberally. The problem is that when faced with such a huge function that calls one non-@safe one, marking the whole thing as @trusted disables all the mechanical verification for everything.
>
> There has to be a better way.
>
> -Steve

But it doesn't have to be accepted into D! :-)

On 2/5/2015 1:15 PM, Steven Schveighoffer wrote:
> So you're saying that @safe is mechanically verified as long as @trusted
> functions are manually reviewed.

Yes.


> It's that manually reviewed part that I think
> we have an issue with. And there is definitely a feel of "I can use trusted
> because I know I will only call it this way" without considering future possible
> calls.

It's no different from:

Q: the compiler gave me a mismatched type error!
A: put in a cast and it'll compile!

I.e. you can always find a way to make buggy, badly designed code compile. It's up to whoever does the reviews to have some sort of standards.


>> An aspect of a well-designed encapsulation is the number of @trusted
>> interfaces is minimized. If you find an abstraction that has @trusted
>> sprinkled liberally through it, it's an indicator of a failed abstraction.
> I think you just made this up :)

No, I've always thought of trusted that way. It isn't different from classes that allow too many functions to access private members.


> But I agree that @trusted should be used sparingly not liberally. The problem is
> that when faced with such a huge function that calls one non-@safe one, marking
> the whole thing as @trusted disables all the mechanical verification for
> everything.

Then that's a candidate for a redesign of the abstraction.

On Thursday, 5 February 2015 at 19:49:41 UTC, Andrei Alexandrescu wrote:
> On 2/5/15 11:17 AM, H. S. Teoh via Digitalmars-d wrote:
>> In short, my proposal is:
>
> Tainted variables are an interesting topic, but quite distinct from the notion of separating safe code from unsafe code.
>
> As much as I was shocked about the use of @trusted/@safe/@system in std.file, std.array and sadly possibly in other places, I found no evidence that the feature is misdesigned. I continue to consider it a simple, sound, and very effective method of building and interfacing robust code. An excellent engineering solution that offers a lot of power at a modest cost.
>
> I do not support this proposal to change the semantics of @trusted/@safe/@system. A separate tainted data proposal might be of interest for loosely related topics.

Probbaly you and Walter should try maintaining Phobos for next year alone then and see how it works. Maybe that will make some issues more convincing.

This is absolutely ridiculous that every single one of existing Phobos reviewers who actually worked with that code in practice says that there is a problem with @trusted and you keep rejecting it with "no, it is all good as it is" argument.

For me this thread was clear alarm : @safe in its current state is a 100% misfeature and is better to be advertised against until either its design changes or effective idioms are presented.

To put it differently - there is no way I would have ever taken the risk merging a 50-line @trusted function, be it Phobos or work project. And it is better to not make promises than to break those.

On 2/5/2015 3:20 PM, Dicebot wrote:
> For me this thread was clear alarm : @safe in its current state is a 100%
> misfeature and is better to be advertised against until either its design
> changes or effective idioms are presented.

I try to address your points in the new thread "@trust is an encapsulation method, not an escape". Please continue there.