@trust is an encapsulation method, not an escape

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 05, 2015 at 05:12:16PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/5/2015 4:13 PM, Dicebot wrote:
> >I know this definition. It have tried it in practice and concluded as
> >being absolutely useless. There is no way I am going to return back
> >to this broken concept - better to ignore @safe completely as
> >misfeature if you insist on doing things that way.
> 
> I'm sorry I haven't been able to convince you. I don't have any more
> arguments other than just repeating myself.
> 
> Moving forward, I must insist that use of @trusted in such a way as to
> make its surrounding context not mechanically checkable is no longer
> acceptable in Phobos.

You are still not getting the point we've been trying to make since the
beginning of this tiresome interminable thread. WE AGREE WITH YOU THAT
@trusted IS MEANT TO BE USED IN THE WAY YOU DESCRIBED!! WE AGREE THAT
std.file NEEDS TO BE FIXED! I hope that gets the point across.

We are not arguing *for* the ugly hacks currently in std.file,
std.array, and wherever else.  What we're trying to tell you, is that
even if we were to rewrite everything the way you prescribe, it will
*still* present the same maintenance issues we have brought up, because
of the way @trusted is implemented. The way it gives free rein to use
whatever @system operations you fancy, with no warnings whatsoever
issued when you did something that's blatantly wrong.  The way it puts a
stamp of @safe-ty approval on what's essentially a @system function
after the initial review, and is never revoked thereafter. The way
changes to @trusted functions are never mechanically checked for basic
@safe sanity. The way a call to a previously @safe function from inside
a @trusted function does not trigger any warning when the callee now
becomes @system.

We are NOT asking you to justify the current state of std.file and
std.array, as you seem to believe we're asking for. Please stop fixating
on that, it's not helping this discussion at all. What we're asking for
is for the compiler to give us the tools to make Phobos maintenance more
tenable.  Like performing @safe checks inside @trusted functions where
possible.  Requiring explicit markup for operations that the compiler
thinks are unsafe, but we know otherwise, so that when somebody comes
along later and introduces more of these operations, the compiler will
issue warnings that prompt reviewers to carefully inspect what has
changed.  Some kind of mechanism for controlling what kind of changes
can be accepted in a @trusted function.

The current state of std.file/std.array/whatever is just a symptom. The
real disease is that we need some way of coping with the maintenance
issues introduced by @trusted. If those issues continue to be neglected,
then other symptoms will just show up elsewhere, even if you rewrite
std.file and std.array now. Until the real issue is addressed, you will
just be playing whack-a-mole on every apparent "abuse" of @trusted that
crops up. It will never end until the real issues are addressed.


> If need be, I will rewrite std.array myself to address this.

Please do. Maybe you will understand more where we're coming from if you
see it for yourself.  Obviously our words mean little to you.  And while
you're at it, try reviewing a few Phobos PR's related to std.array as
well, and observe for yourself the maintenance issues that arise.


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous