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
