On 2/5/15 5:23 PM, H. S. Teoh via Digitalmars-d wrote:
> It is a desperate attempt to contain a
> maintenance problem that's growing out of hand.

Before we get into this - do you have evidence of the maintenance problem that's growing out of hand? E.g. bugs in std.file that were fixed etc. Thanks. -- Andrei

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

On 2/5/15 5:53 PM, H. S. Teoh via Digitalmars-d wrote:
> 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.

Again, could you please collect past evidence of such? According to you there must be many cases in which there was insufficient safety checking that was hiding bugs etc.

Evidence would do wonders for your argument.


Andrei

On Friday, 6 February 2015 at 02:06:29 UTC, Andrei Alexandrescu wrote:
> On 2/5/15 5:53 PM, H. S. Teoh via Digitalmars-d wrote:
>> 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.
>
> Again, could you please collect past evidence of such? According to you there must be many cases in which there was insufficient safety checking that was hiding bugs etc.
>
> Evidence would do wonders for your argument.
>
>
> Andrei

Evidence does wonders for any argument!

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

On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
> (2) I don't think the proposal you sketched at http://goo.gl/JWqafx is good.

The goo link is disabled for violating goo's terms of service, whatever that means.

What's the real url?

On 2/5/15 6:52 PM, Walter Bright wrote:
> On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
>> (2) I don't think the proposal you sketched at http://goo.gl/JWqafx is
>> good.
>
> The goo link is disabled for violating goo's terms of service, whatever
> that means.
>
> What's the real url?

http://forum.dlang.org/thread/mb070a$1ok1$1@digitalmars.com#post-mailman.6039.1423163991.9932.digitalmars-d:40puremagic.com

Andrei

On 2/5/2015 7:00 PM, Andrei Alexandrescu wrote:
> On 2/5/15 6:52 PM, Walter Bright wrote:
>> On 2/5/2015 6:26 PM, Andrei Alexandrescu wrote:
>>> (2) I don't think the proposal you sketched at http://goo.gl/JWqafx is
>>> good.
>>
>> The goo link is disabled for violating goo's terms of service, whatever
>> that means.
>>
>> What's the real url?
>
> http://forum.dlang.org/thread/mb070a$1ok1$1@digitalmars.com#post-mailman.6039.1423163991.9932.digitalmars-d:40puremagic.com

Thank you. Essentially, the proposal attaches safe/trusted/system to variables. I don't believe this works. Safety/unsafety can often be the emergent combination of state of many otherwise 'safe' variables.

In any case, it lacks any demonstration of how it would address the problems in std.array. I.e. how could it insure that the code that initializes the array in std.array.join() initializes every element? (That loop is in the 'safe' section!)

I don't see how any proposal can work unless it specifies a safe interface to an unsafe section of code. (I read a Rust tutorial that rather bluntly pointed this out as well.)

On Friday, 6 February 2015 at 03:14:59 UTC, Walter Bright wrote:
> I don't see how any proposal can work unless it specifies a safe interface to an unsafe section of code. (I read a Rust tutorial that rather bluntly pointed this out as well.)

Link?

On Friday, 6 February 2015 at 01:12:18 UTC, Walter Bright 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.

This is not about convincing but about showing the example yourself. My disagreement is not theoretical - I trust you to be much better in actual language design. But trusting alone won't make a difference if I have no idea how use it in practice (after trying and failing).

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.

> But D is a systems programming language, not a B&D language, and anyone will be free to ignore @safe and continue to use the other benefits of D, or use @safe in a way that conforms to their own formulation of best practices.

It always feel awkward to ignore what was supposed to be a major selling point for a language :(