https://issues.dlang.org/show_bug.cgi?id=14125

Zach the Mystic <reachzach@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reachzach@gmail.com

--- Comment #48 from Zach the Mystic <reachzach@gmail.com> ---
(In reply to Walter Bright from comment #47)
> (In reply to Andrei Alexandrescu from comment #45)
> > That's beautiful. Too bad it doesn't work :o).
> 
> I did say I paraphrased it. I've come out against supporting
> 
>    @trusted { ... code ... }
> 
> because it made it too easy to do bad things with it. But I did use it to make for a simpler example :-)

I think it would be funny if a @trusted function with fewer than two statements was automatically rejected by the compiler. Since an unverifiable, but @safe operation requires two actions, one to dive into unsafe territory, and a second one to dive back out, any sound use of @trusted *must* have two or more statements. Destroy! :-)

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #49 from David Nadlinger <code@klickverbot.at> ---
(In reply to Walter Bright from comment #44)
> I understand you want the ...safe code... to be checked for safety.

No. I want the "...safe code...", which is in fact "...code that might be safe depending on the template arguments...", to trigger attribute inference as usual, while the compiler should trust me on the potentially-unsafe-but-manually-verified part (such as the cast, or a temporary allocation, etc.).

The hypothetical @safe blocks won't help there. @trusted blocks would.

I seriously don't see how you could view the latter as more dangerous than applying the attribute to the whole function. In fact, the difference might even boil down to just setting STCtrusted on a smaller scope instead of the function scope. There is still a big, red "@trusted" token in the code to catch the reviewer's eye (well, the color obviously depends on your syntax highlighter settings).

In fact, I think that @trusted blocks make it easier to write and review high-quality code, as they help to reduce the amount of lines that need to be reviewed. (Of course, having two @trusted blocks in what would otherwise be a three-liner might not be worth it in that regard, as Andrei pointed out.)

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #50 from Zach the Mystic <reachzach@gmail.com> ---
(In reply to Zach the Mystic from comment #48)
> I think it would be funny if a @trusted function with fewer than two statements was automatically rejected by the compiler. Since an unverifiable, but @safe operation requires two actions, one to dive into unsafe territory, and a second one to dive back out, any sound use of @trusted *must* have two or more statements. Destroy! :-)

I'm kidding, but unfortunately, it does seem like @trusted's purpose is never going to be easily communicated. Maybe something in the documentation saying that a @trusted function must have more than one action to be used correctly?

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #51 from David Nadlinger <code@klickverbot.at> ---
(In reply to Andrei Alexandrescu from comment #42)
> Sigh, std.array has become another disaster area we need to clean.

What about just giving it a try? You might even discover that there actually is a language issue to be solved here (assuming that the current situation is unacceptable).

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #52 from Dicebot <public@dicebot.lv> ---
(In reply to David Nadlinger from comment #51)
> (In reply to Andrei Alexandrescu from comment #42)
> > Sigh, std.array has become another disaster area we need to clean.
> 
> What about just giving it a try? You might even discover that there actually is a language issue to be solved here (assuming that the current situation is unacceptable).

This.

Judging by this thread there seems to be a huge distance between language authors and people trying to actually use those language features in practice. It is hard to communicate when it is simpyl assumed that I don't understand how @trusted and @safe work (and are supposed to work) instead of addressing actual real-world problems that we encounter.

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #53 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to David Nadlinger from comment #51)
> (In reply to Andrei Alexandrescu from comment #42)
> > Sigh, std.array has become another disaster area we need to clean.
> 
> What about just giving it a try?

Give what a try? The cleanup?

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #54 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Dicebot from comment #52)
> (In reply to David Nadlinger from comment #51)
> > (In reply to Andrei Alexandrescu from comment #42)
> > > Sigh, std.array has become another disaster area we need to clean.
> > 
> > What about just giving it a try? You might even discover that there actually is a language issue to be solved here (assuming that the current situation is unacceptable).
> 
> This.
> 
> Judging by this thread there seems to be a huge distance between language authors and people trying to actually use those language features in practice. It is hard to communicate when it is simpyl assumed that I don't understand how @trusted and @safe work (and are supposed to work) instead of addressing actual real-world problems that we encounter.

Do you have any response to the counterarguments made to yours? I think it's rather clear how Walter and I stand, and also where you are wrong.

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #55 from Dicebot <public@dicebot.lv> ---
I don't see any counterarguments, only trying to explain what @trusted is suppposed to mean (which I am perfectly aware of). It does not address "break @trusted by adding code" concern which is a different thing - and which we were trying to fix by this idiom within available language limitations.

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #56 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Dicebot from comment #55)
> I don't see any counterarguments, only trying to explain what @trusted is suppposed to mean (which I am perfectly aware of). It does not address "break @trusted by adding code" concern which is a different thing - and which we were trying to fix by this idiom within available language limitations.

The illusion that @trusted wrappers around essentially unsafe operations make any difference has been shattered.

--

https://issues.dlang.org/show_bug.cgi?id=14125

--- Comment #57 from Dicebot <public@dicebot.lv> ---
You shouldn't consider those wrapper really @trusted - they have _never_ supposed to be ones. It is simply a workaround for bunch of language limitations. I'd love to have something better to address the issue - not regress to worse solution because workaround was not good enough.

--