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
