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
