On 23/05/2020 5:07 AM, Atila Neves wrote:
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote:
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote:
With the rationale laid out clearly as it is here, I do have some
responses in mind. But before sharing them, I'd like to know whether
that would be useful right now: I've no wish to just press for a
re-hashing of conversations that have already been had.
No.
This wasn't the first and certainly won't be the last time we as a
community have been very unhappy with how Walter conducts himself with
his DIP's.
Although it seems an improvement has been made to how he needs to
respond to the DIP assessment. It should also include a statement from
Atila as well given his position.
I'm going through posts in order, so apologies if I'm "ignoring"
something that shows up later in the discussion.
Personally and initially, I would have preferred it if non-extern(D)
declarations were implicitly @system. I understood Walter's argument
about special cases and how they're bad, but the thought of them being
@safe made me feel, for lack of a better word, "icky".
This is one of the issues I had a problem with.
It is not about the linkage.
The problem is solely does the compiler have the source to the function
body to verify it?
Then I talked to Walter and he pointed out that if those declarations
were @system, users would be prevented from calling them from now @safe
code. A regular user would probably just slap `@safe:` at the top of the
bindings module anyway. Then I realised that I did exactly that with my
libclang bindings:
https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L254
That is a failure of the language that should be resolved.
One of the arguments that has been brought up (although I don't remember
if it made its way to the N.G.) is that if you don't have the body, can
a function /even/ be @safe?
"Worse", I made all functions `pure` and all parameters `in` as well for
good measure. Why? I wanted to call them from my @safe pure code with
`const` arguments. My reasoning at the time was "I trust libclang".
You might, but that doesn't give the compiler the right to do so by
default. This a decision for a skilled programmer to make.
And so I was convinced that everything being @safe is actually ok,
especially because in real life, most C/C++ APIs aren't going to
secretly corrupt your code.
What you did was give up some security in favor of freedom and now you
can't get certified to work on top secret projects (analogy).
Then there's the fact that, today, there's no safety anyway calling
anything because everything is @system by default. And D source code
won't be able to lie.
Does that clear it up?
No.
We simply do not agree, nor do I expect for us to come to terms on it
anytime soon.
To me at least, this butchers @safe/trusted/system into a system that is
near useless for guarantees for an entire program.
Sure its convenient for a single function, but absolutely useless in
trying to solve the actual problem it was trying to solve in the first
place.
