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".
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
"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".
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.
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?