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