DIP1028 - Rationale for accepting as is
rikki cattermole
rikki at cattermole.co.nz
Fri May 22 17:33:11 UTC 2020
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.
More information about the Digitalmars-d-announce
mailing list