@trust is an encapsulation method, not an escape

[Andrei Alexandrescu via Digitalmars-d]

On 2/5/15 5:23 PM, H. S. Teoh via Digitalmars-d wrote:
> This whole discussion has been very tiring and frustrating, because we
> keep talking past each other. The reason we keep talking past each other
> is because we keep conflating several distinct, though related, issues.

Bummer about that. Let's see.

> 1) I think we all basically agree that std.file is a mess and some
> solution is needed to fix this mess. I don't think anyone is actually
> advocating *for* the code that's currently in std.file right now. So can
> we pretty please agree that this is a given, and stop using it to beat
> each other over the head?

There remains the issue - is the messy @trusted code a net negative or 
not? If so, why did it pass review? That would be an interesting case 
study for improving our review process. I find it difficult to reckon 
that that code got into a Phobos release.

> 2) I think we also all basically agree that the *intent* of @trusted is
> to be an encapsulation mechanism, or to present a safe API, or however
> you want to describe it. I.e., if a function is marked @safe, then it
> must be impossible to cause it to do something unsafe by passing it the
> wrong arguments. Whatever it does under the hood should not have any
> observable unsafe effect on the outside world. I'm pretty sure everyone
> also agrees with this; I don't think anyone is advocating that we should
> changee this intent. So can we please also take this as a given, and
> stop repeating it at each other as if we don't all already know it?

Yah.

> This leaves the core of the contention, which is that @safe/@trusted, as
> currently implemented, presents maintenance difficulties.

I think these difficulties have not been demonstrated.

> Walter &
> Andrei don't seem to be convinced that this is a problem, but the
> evidence is right before us.

Pray tell.

> We Phobos committers did not deliberately
> set out to sabotage @trusted by introducing blatant abuses of it just
> for fun (see (1) and (2) above). The current ugly (and arguably totally
> wrong) hacks are a symptom of the underlying maintenance difficulty that
> the current system presents. It is a desperate attempt to contain a
> maintenance problem that's growing out of hand.

Could you please show the numerous bugs and subsequent commits fixing 
them that you are alluding to?

I'll stop quoting here. My understanding of your core argument is as 
follows:

"Currently there is no safety verification for @trusted functions, and 
it would be nice if there were more."

I'm totally on board with this. It would definitely be nice to have more 
verification. That said:

(1) I am not convinced this is a problem as large as you want it to be. 
I find most of your arguments to appeal to unsubstantiated hyperbole.

(2) I don't think the proposal you sketched at http://goo.gl/JWqafx is good.

Now, there must be a way to convey this to you without personally 
offending you: I think your proposal is not good. I don't buy it. It's 
poorly motivated, poorly argued, it's very incomplete, it complicates 
the language without visible benefit, it's just not what I'd think we 
should be doing.

If you have a better proposal, please let's have it. To be honest I 
don't think a reasonable amount of work on http://goo.gl/JWqafx will 
make it better.

How can I say "after carefully learning about your points and proposal I 
think we should do as Walter and I say and not as you say" without 
insulting you?


Andrei