On Saturday, 4 December 2021 at 03:23:07 UTC, rikki cattermole wrote:
> Quite literally one small change, no function body? @system and we would have supported the DIP.
>
> Nobody has stepped up to make an amended DIP however.

I do not entirely understand this reply.  It seems that you are saying that this would have happened - with support from Walter - had a little more paperwork been done.  Can you confirm?

I don't really know how to submit a DIP but I will figure it out if that is really all that is needed.  But I'm skeptical ... I've read these forms long enough to know that people generally don't put in the effort to work through the red tape because, frequently, that is done and the proposal winds up being killed anyway.

I'm willing to help out, provided either (A) the proposal cannot be unilaterally killed by Walter, or (B) he personally confirms that he is on board.

On 06/12/2021 7:09 AM, Greg Strong wrote:
> On Saturday, 4 December 2021 at 03:23:07 UTC, rikki cattermole wrote:
>> Quite literally one small change, no function body? @system and we would have supported the DIP.
>>
>> Nobody has stepped up to make an amended DIP however.
> 
> I do not entirely understand this reply.  It seems that you are saying that this would have happened - with support from Walter - had a little more paperwork been done.  Can you confirm?

The problem was Walter didn't listen to the community. We said pretty much from day one, if you can't prove that a function is @safe, it simply cannot default to it. As that breaks the guarantee (there is some conflating of ABI with safety-ness although if a function is extern(C) it shouldn't effect it).

It went through the DIP process without this change.

The accepted thread: https://forum.dlang.org/thread/rwjxbgsauknjjrvousti@forum.dlang.org
Thread where he announced it was dead: https://forum.dlang.org/thread/raq4fg$1ab4$1@digitalmars.com

> I don't really know how to submit a DIP but I will figure it out if that is really all that is needed.  But I'm skeptical ... I've read these forms long enough to know that people generally don't put in the effort to work through the red tape because, frequently, that is done and the proposal winds up being killed anyway.
> 
> I'm willing to help out, provided either (A) the proposal cannot be unilaterally killed by Walter, or (B) he personally confirms that he is on board.

This is in a pretty awkward position. Community is ok if it has this one change, but we don't know what Walter's position is on an amended DIP would be. There are some sour feelings here I think still.

On Sunday, 5 December 2021 at 18:24:22 UTC, rikki cattermole wrote:
> This is in a pretty awkward position. Community is ok if it has this one change, but we don't know what Walter's position is on an amended DIP would be. There are some sour feelings here I think still.

Thanks, Rikki, for your quick and frank reply.  This is what I feared.  No one wants to put in significant effort, understandably, when there is a good chance it will be unilaterally killed even if the entire rest of the community is in favor.

D has a real problem.  On the one hand, we have problems moving forward.  No need to reiterate those.  But, on the other hand, there is no long-term-support (LTS) release, nor so far as I know, any plans for an LTS release, so you can't rely on the current state either.  This makes D only useful for hobby programming.

I know there are plans for a new model of governance.  I hope that helps.  But I have so far seen nothing on these forums that gives me confidence.

@Mike Parker, here's a clear opportunity for the new governance model to sink-or-swim.  It seems the entire community, except for Walter, wants this but it has been unilaterally killed.  Can we move forward?  If you need me to do the paperwork, I will.  If this still cannot go forward under the new model, then the new model must be considered a failure and it's time to move on.

On Sunday, 5 December 2021 at 18:09:56 UTC, Greg Strong wrote:
> I'm willing to help out, provided either (A) the proposal cannot be unilaterally killed by Walter, or (B) he personally confirms that he is on board.

B is the most realistic option, people are rarely willing to give up ultimate power for both good and bad intentions.

No matter how I think about, extern(C) being @safe by default makes no sense. Even if it was written in a different language, you have no information about *which* language and what safety guarantees it (doesn't) provide. I just wish it wasn't the main point of contention for @safe by default :(

Honestly I'd go as far as saying no C code should be marked as even @trusted by a human (even wrapper funcs). But that unfortunately turns into a "D with C" (@safe + @"trusted") vs "D with no C"(@safe only) kind of argument.

And there's no where near enough libraries in D to make up for not being able to interface with C.

While it's really unfortunate we haven't yet gotten @safe by default, I'm still weary about it when code is still interfacing with possible non-@safe languages via extern(C).

On Sunday, 5 December 2021 at 19:57:18 UTC, SealabJaster wrote:
> Honestly I'd go as far as saying no C code should be marked as even @trusted by a human (even wrapper funcs). But that unfortunately turns into a "D with C" (@safe + @"trusted") vs "D with no C"(@safe only) kind of argument.

This is a step too far, I think. There are several functions which are guaranteed by the C standard to never invoke undefined behavior (e.g., getchar, rand, everything in <math.h>). Allowing functions like these to be marked as @trusted is completely legitimate.

On Sunday, 5 December 2021 at 21:53:36 UTC, Paul Backus wrote:
>There are several functions
> which are guaranteed by the C standard to never invoke undefined behavior (e.g., getchar, rand, everything in <math.h>). Allowing functions like these to be marked as @trusted is completely legitimate.

Most standalone functions and even syscalls can be made safe with a thin wrapper. The real challenge is a framework that presumes manual memory management. Difficult to deal with, maybe importC can enable some static analysis?

On 06/12/2021 7:45 AM, Greg Strong wrote:
> Thanks, Rikki, for your quick and frank reply.  This is what I feared.  No one wants to put in significant effort, understandably, when there is a good chance it will be unilaterally killed even if the entire rest of the community is in favor.

Nah this particular change would probably take all of 2 minutes.

I've written a DIP and had it go through the queue myself.

In this particular case its just a matter of waiting while peoples emotions calm down some more and hear from Walter that we can proceed.

On Sunday, 5 December 2021 at 21:53:36 UTC, Paul Backus wrote:
> ...

I should've mentioned that I *do* expect exceptions to that statement, especially in regards to things where interfacing to C is near enough mandatory (WinAPI, sockets, etc.)

But as the other post said, it's a really hard issue to make something fully @safe if it also includes manual memory management - a route D could be heading in regards to allocators.

On Sunday, 5 December 2021 at 18:09:56 UTC, Greg Strong wrote:
>
> I'm willing to help out, provided either (A) the proposal cannot be unilaterally killed by Walter, or (B) he personally confirms that he is on board.

Option C would provide you with that and that would be that D is forked and that project is managed better. Say hello to D++, or whatever better name you can come up with.