Re: DIP 1028 "Make @safe the Default" is dead

2020-05-29 Thread Johannes T via Digitalmars-d-announce
On Friday, 29 May 2020 at 04:53:07 UTC, Walter Bright wrote: The subject says it all. Thanks a lot for your effort! Judging by the responses, there should be another attempt after addressing some issues. I have an idea that could mitigate greenwashing of extern (I know everyone hates that

Re: Rationale for accepting DIP 1028 as is

2020-05-27 Thread Johannes T via Digitalmars-d-announce
On Wednesday, 27 May 2020 at 10:51:54 UTC, Walter Bright wrote: [..] I was reading Bastiaan's inspiring ideas about provable verification of @trusted and something occurred to me. If we are serious about safety, we should consider @trusted annotation on extern C harmful. It provides little

Re: DIP1028 - Rationale for accepting as is

2020-05-26 Thread Johannes T via Digitalmars-d-announce
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

Re: DIP1028 - Rationale for accepting as is

2020-05-25 Thread Johannes T via Digitalmars-d-announce
On Monday, 25 May 2020 at 12:22:25 UTC, Zoadian wrote: [..] there is no such thing as a trustworthy @trusted. [..] Sorry, my bad. I meant the quality of @trusted annotations would decline.

Re: DIP1028 - Rationale for accepting as is

2020-05-25 Thread Johannes T via Digitalmars-d-announce
On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote: On 25.05.20 11:25, Johannes T wrote: @trusted can't be trusted That's the point of @trusted. ._. The code is trusted by the programmer, not the annotation by the compiler. Sorry, I phrased it poorly. I meant @trusted would be used

Re: DIP1028 - Rationale for accepting as is

2020-05-25 Thread Johannes T via Digitalmars-d-announce
On Monday, 25 May 2020 at 10:19:22 UTC, Johannes Loher wrote: [..] But with the DIP in its current form, we make @safe lose its meaning and power, which is much worse in my opinion. [..] The alternative, not making extern @safe, would result in more untrustworthy @trusted code we have to

Re: DIP1028 - Rationale for accepting as is

2020-05-25 Thread Johannes T via Digitalmars-d-announce
On Monday, 25 May 2020 at 00:56:04 UTC, Timon Gehr wrote: [..] After thinking about it, Walter ultimately made the right decision, leading to overall higher safety and code quality. We all agree that making extern C @safe is incorrect. It's also meaningless. Even if you were to verify the

Re: DIP1028 - Rationale for accepting as is

2020-05-24 Thread Johannes T via Digitalmars-d-announce
On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote: I'd like to emphasize: [..] Thank you. I do see the picture now. When taking safety seriously, you would find unannotated declarations and audit/annotate them. It is not worthy of a compile option. An average user is, from

Re: DIP1028 - Rationale for accepting as is

2020-05-23 Thread Johannes T via Digitalmars-d-announce
On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote: I have made these points before, but I'll summarize them here for convenient referral. [..] Thank you for the detailed and insightful explanation. Would it be feasible to have a follow-up DIP that enables implicit @system extern as