On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> 3. Wrap the call to massage_data() with:
>
>     () @trusted { massage_data(parameters); } ();

The correct solution is to encapsulate the C functions as-needed with a higher level API - and this is somewhat commonly done already and - as i understand it anyway - the whole purpose of @trusted being function level instead of statement level.

> 2. Existing, working code breaks.

@safe by default is probably the biggest breaking change D has ever seen as of this point. It eclipses anything in the D2 transition.

It is D3 in all by name. My preference, as I've said many times, is to fix the propagation of attributes into child scopes and leave the defaults alone, but failing that, I'd actually say embrace this: if we're doing big breakage anyway, go big and do it right.

On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
> On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
>>
>> As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now.
>>
>> And again why waste time with this process plus 2 rounds of discussion?
>>
>> I mean just do it and tell in this announcement section about the feature.
>>
>
> The DIP review process is not intended for community approval or rejection of DIPs. It's not a democratic voting process. It's intended to elicit community feedback to enhance the DIP under review (the Feedback Threead) and to allow the airing of opinions (the Discussion Thread). All DIP authors have the freedom to incorporate suggestions into their DIP or not, and Walter and Atila make the decision to accept or reject. If you look at the history of Walter's DIPs, they *do* take the opinions into consideration even when he is the author. Several of his previous DIPs have been withdrawn or rejected.
>
> If a popular DIP is rejected, it means neither of them were convinced by opinion to accept it. And, as in the case for this DIP, if an unpopular DIP is accepted, it means they were not persuaded by the arguments against it.
>
> From my perspective, the process is working as intended, despite the comments to the contrary in this thread. You either convince a DIP author to modify his DIP, or you don't. You either persuade Walter and Atila to accept or reject it, or you don't.

I think the source of the problem is that Walter's DIPs require the community to prove that Walter's proposal is so bad that he needs to reject it. Anyone else's proposal has to prove that it's worthy of being added to the language. There's a big perceived gap between those two. As I've said many times, it's odd for someone to judge his own DIPs, and as someone that is an academic administrator and runs a high-profile journal, I can say this type of practice is not the norm in those areas because it doesn't lead to good decisions.

On 22.05.20 15:58, bachmeier wrote:
> ...
> 
> Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical?

Honesty is what's critical. The annotations should mean what they are advertised to mean and making those meanings as simple as possible makes them easier to explain. As things stand, @safe can mean that someone accidentally or historically did not annotate an extern(C) prototype and an unsafe API a few calls up was ultimately exposed with the @safe attribute because the compiler never complained.

How would you feel if you never intended to expose a @safe interface, but someone imported your library after determining it contained no @trusted annotations (following the advice of articles on @safe), relied on the @safe annotation and then had weird sporadic memory corruption issues in production that took them months to ultimately trace back to your library? Would you feel responsible or would you rather put the blame on Walter?

On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote:
> On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote:
>> On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote:
>>> This is the nightmare scenario that people are worried about: safety violations
>>> being introduced *silently* into existing, correct D code.
>>
>> Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical?
>
> The problem isn't that safety is critical, it's that the D compiler is lying to me about the safety of my code.
>
> If the compiler was honest and told me that my code was unsafe, I'd be able to make an informed decision to either (a) accept the lack of safety, or (b) do the additional work needed to make it safe. As-is, DIP 1028 takes that choice away from me, and I am forced to accept a lack of safety whether I want to or not. At that point, why not use C?

If you're compiling a program that calls into C, you know that's what you're doing, so you know you've given up any guarantees of safety. Back in the early days of Rust, someone made a comment along the lines of Rust being a language to rewrite C code in, not to use to call C code. D has, to this point, been a language designed to interoperate easily with C code. I personally don't care about safety guarantees at all. It's not obvious to me that guaranteed safety at all costs is the way to go - especially considering the degree to which that breaks from current behavior.

On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote:
> On 22.05.20 15:58, bachmeier wrote:
>> ...
>> 
>> Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical?
>
> Honesty is what's critical. The annotations should mean what they are advertised to mean and making those meanings as simple as possible makes them easier to explain. As things stand, @safe can mean that someone accidentally or historically did not annotate an extern(C) prototype and an unsafe API a few calls up was ultimately exposed with the @safe attribute because the compiler never complained.

In my opinion, the only advantage of @safe is that the compiler has checked the code and determines that it only does things considered safe. I don't see that marking an extern(C) function @trusted buys you anything, at least not until you can provide a compiler guarantee for arbitrary C code.

On Friday, 22 May 2020 at 14:43:27 UTC, bachmeier wrote:
> If you're compiling a program that calls into C, you know that's what you're doing, so you know you've given up any guarantees of safety.

The entire problem is that with DIP 1028, I *don't* know what I'm doing, because the compiler will silently allow me to write @safe D code that calls into unsafe C code.

Keep in mind that none of this requires *me* to write the call to C directly. It could be buried several layers deep in a dependency, and merely cause a D function I call to be incorrectly inferred as @safe.

On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
> On Friday, 22 May 2020 at 12:47:04 UTC, matheus wrote:
>>
>> As an end user, I'd like to know if this language will be guided by community or one person, because it seems the "democracy" is very shallow right now.
>>
>> And again why waste time with this process plus 2 rounds of discussion?
>>
>> I mean just do it and tell in this announcement section about the feature.
>>
>
> The DIP review process is not intended for community approval or rejection of DIPs. It's not a democratic voting process. It's intended to elicit community feedback to enhance the DIP under review (the Feedback Threead) and to allow the airing of opinions (the Discussion Thread). All DIP authors have the freedom to incorporate suggestions into their DIP or not, and Walter and Atila make the decision to accept or reject. If you look at the history of Walter's DIPs, they *do* take the opinions into consideration even when he is the author. Several of his previous DIPs have been withdrawn or rejected.

No dispute here.

>
> If a popular DIP is rejected, it means neither of them were convinced by opinion to accept it. And, as in the case for this DIP, if an unpopular DIP is accepted, it means they were not persuaded by the arguments against it.
>

Not exactly.  IIUC logical "and" is required for approval.  One of the two might have been persuaded to accept.  "not and", a single disapproval, suffices for rejection.  I believe this is a useful weighting.

> From my perspective, the process is working as intended, despite the comments to the contrary in this thread. You either convince a DIP author to modify his DIP, or you don't. You either persuade Walter and Atila to accept or reject it, or you don't.

Again, IIUC, you either persuade Walter *or* Atila to reject or you don't.  Apropos of which, what does Atila think of this DIP?

On Friday, 22 May 2020 at 14:37:04 UTC, bachmeier wrote:
>
> I think the source of the problem is that Walter's DIPs require the community to prove that Walter's proposal is so bad that he needs to reject it. Anyone else's proposal has to prove that it's worthy of being added to the language. There's a big perceived gap between those two. As I've said many times, it's odd for someone to judge his own DIPs, ...

When either Walter or Atila author a DIP, their spot in the "convince both or face rejection" duopoly could be taken by another person.

On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote:
> The DIP review process is not intended for community approval or rejection of DIPs. It's not a democratic voting process.

The community needs to unite and fix this. It is an ineffectual process that leads to worse results for the language and further poisons the relationship between us.

A small voting review committee solves these problems.

On 22.05.20 16:49, bachmeier wrote:
> On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote:
>> On 22.05.20 15:58, bachmeier wrote:
>>> ...
>>>
>>> Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical?
>>
>> Honesty is what's critical. The annotations should mean what they are advertised to mean and making those meanings as simple as possible makes them easier to explain. As things stand, @safe can mean that someone accidentally or historically did not annotate an extern(C) prototype and an unsafe API a few calls up was ultimately exposed with the @safe attribute because the compiler never complained.
> 
> In my opinion, the only advantage of @safe is that the compiler has checked the code and determines that it only does things considered safe.

Wrong, but let's roll with that.

> I don't see that marking an extern(C) function @trusted buys you anything, at least not until you can provide a compiler guarantee for arbitrary C code.

It buys you the ability to call that function from @safe code. Clearly you can't mark it @safe because the compiler has not checked it.