On Wednesday, 27 May 2020 at 10:06:41 UTC, rikki cattermole wrote:
> On 27/05/2020 10:03 PM, Walter Bright wrote:
>> Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish.
>
> Okay, how is your camera and mic situation?
>
> Lets do a Twitch stream, make sure there are some moderators in place as well.
>
> Open to everybody and it can be recorded by Twitch.

Youtube streams work better in my experience.

On 27/05/2020 10:12 PM, Johannes Loher wrote:
> Am 27.05.20 um 11:25 schrieb Walter Bright:
>> On 5/24/2020 3:40 AM, Stefan Koch wrote:
>>> The distinction is that you can find a slapped on trusted with a grep.
>>
>> It's just as easy to use grep to *not* find @trusted.
> 
> But that's not enough. You need a regexp that searches for extern
> (C(++)) declarations that do not have any of @safe, @trusted, @system.
> The attributes can also be either before the return type + name +
> parameters or after it. They can also be mixed with any other
> attributes. Sure, you can probably write a regex that matches all of
> this but it is a _lot_ more complicated than simply searching for @trusted.

extern(Windows)
extern(System)

COM

Few more things there.

On 5/27/2020 3:06 AM, rikki cattermole wrote:
> Open to everybody and it can be recorded by Twitch.

I've done the video conferencing many times over the decades. I just don't find it to be productive. Maybe it's some defect in me.

They usually go something like this:

"Who else is here?"
"Hello ... Hello?"
"Can anybody hear me? Is my mike working?"
"Where's Bob? Is he connected?"
"I just got my connection working again. What did I miss?"
"Bob? Bob?"
"Can someone go find Bob?"
"Can you say that again? The audio cut out."
"Bob here!"
"Hmm. We lost Bob again?"
"Fred, can you please turn off your motorcycle?"
"Bob here again! Sorry!"
"Fred? Now where's Fred? Fred?"

What has always worked best for me is a face to face over coffee and/or beer.

Which is why I'm missing DConf this year terribly.

Am 27.05.20 um 11:50 schrieb Walter Bright:
> 
> It is a fair point.
>

By the way, thank you for acknowledging that. I appreciate it.

On 5/27/2020 3:07 AM, Johannes Loher wrote:
> This is a very specific situation. There are a lot of teams / developers
> that do not work in this manner. I don't know the numbers so I will make
> no statement about what is more common but my personal experience is a
> different one.

I've seen larger companies operate this way. Smaller ones cannot afford to.


> Also what is the difference between your QA department telling you to
> correctly annotate C declarations and the compiler telling you that?
> If you expect people to ignore what the compiler is telling them, why do
> you expect them to listen to the QA department?

The QA dept is motivated to not be taken in by greenwashing.

(Back in my days at Boeing, I worked in the design department. There was an entirely separate organization call the Stress Group. Their job was to sign off on every nitpicky detail. If they signed off on something that turned out to be wrong, it was bad for their careers. Your designs did not move forward without Stress signoff. If you tried to trick Stress, that was the end of your career at Boeing.)

So yeah, there's a huge difference between tricking the compiler and tricking the QA department.


> In my opinion, the
> compiler actually _is_ one of the best QA departments.

Indeed it is, and that's the whole point to @safe. My motivation here is make suspicious code stand out. @trusted code does not stand out so much, because it is required to exist.


> Also in my opinion, a competent QA department should carefully look at
> any @trusted code /declarations. Maybe it is not a "red flag" but it is
> definitely something that needs to be checked with extra care.

Looking at un-annotated declarations should be the first step. If it is annotated with @trusted, at least there's the coffee stain on the drawing indicating that somebody looked at it.

On 5/27/2020 2:34 AM, Bastiaan Veelo wrote:
> On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
>> On 5/26/2020 11:20 PM, Bruce Carneal wrote:
>>> I'm not at all concerned with legacy non-compiling code of this nature.
>>
>> Apparently you agree it is not an actual problem.
> 
> Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me.

His argument was:

"Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked.  Post 1028, IIUC, the compilation will go through without complaint.  This seems quite clear.  What am I missing?"

I replied that it was unlikely that such legacy code existed.

He replied that he was not concerned about it.

I.e. working legacy code is not going break.

On 5/27/2020 3:01 AM, Timon Gehr wrote:
> This is clearly not possible, exactly because the old @safe rules are stronger. 

Thank you. We can agree on something.

> But why exactly should API breakage not count?

I've addressed exactly this a dozen times or more, to you and others. Repeating myself has become pointless.

It's fine to disagree with me. Argue that point. But don't say I didn't address it.

Am 27.05.20 um 12:40 schrieb Walter Bright:
> 
> Indeed it is, and that's the whole point to @safe. My motivation here is make suspicious code stand out. @trusted code does not stand out so much, because it is required to exist.

By that logic, wouldn't it also make more sense to implicitly default to @trusted instead of @safe for any unannotated D code?

Following that logic, if @safe is the default and somebody writes
non-@safe code without annotating it, it won't compile they might just
slap @trusted on it without actually checking it. By that they make it
harder for the QA department to spot.
If @trusted was the default, it would compile, there would be no
annotation on it an the QA department would see it is a red flag.

What's the difference here?

On Wednesday, 27 May 2020 at 10:46:11 UTC, Walter Bright wrote:
> On 5/27/2020 2:34 AM, Bastiaan Veelo wrote:
>> On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote:
>>> On 5/26/2020 11:20 PM, Bruce Carneal wrote:
>>>> I'm not at all concerned with legacy non-compiling code of this nature.
>>>
>>> Apparently you agree it is not an actual problem.
>> 
>> Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me.
>
> His argument was:
>
> "Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked.  Post 1028, IIUC, the compilation will go through without complaint.  This seems quite clear.  What am I missing?"
>
> I replied that it was unlikely that such legacy code existed.
>
> He replied that he was not concerned about it.
>
> I.e. working legacy code is not going break.

The legacy code is not the issue, never was.
It always was about unsafe code that will become @safe with that DIP.
Safe code is safe and DIP doesn't change that.
It's all about UNSAFE code becoming magically labelled SAFE by the compiler but that is still UNSAFE in reality.

On 5/27/20 6:03 AM, Walter Bright wrote:
> On 5/26/2020 5:20 AM, Johannes T wrote:
>> On Tuesday, 26 May 2020 at 03:37:29 UTC, Walter Bright wrote:
>>> [..]
>>
>> Thank you very much for your patience with all the negative feedback. I get your decision to not annotate extern C with @system by default. The biggest issue with extern @system is that @trusted would become less useful when dealing with declarations and bindings. @trusted would appear more frequently. We wouldn't be able to assume that the author put in effort in assessing the trustworthiness of a declaration. More greenwashing, less safety. Those are severe drawbacks, I agree.
>> However, as Andrei pointed out, PR is a huge problem. We need to be able to sell it with a straight face.
> 
> Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish.

Didn't work with me.