On Thursday, 21 May 2020 at 20:46:09 UTC, Walter Bright wrote:
On 5/21/2020 9:14 AM, Seb wrote:
Why we can't we have a technical board where the community can
vote in experts and potentially companies could even buy a
seat for $$$ which would mean a lot more for them than the
current very vague sponsorship options.
I'm aware that Walter doesn't like the idea of giving up
ownership, but it makes all the other people question why they
should still bother with this process and not simply fork and
move to an open, transparent development...
I expected flak from this decision. I'm prepared to take the
flak because this is the right decision. I did not make it
lightly.
That's interesting that you are saying it is the "right"
decision. Let's analyze that for a second:
What this boils down to is
Simplicity Vs. Memory Safety
Is the **correct** code actually simpler? A beginner that doesn't
have the knowledge of D's safety system will ultimately create C
bindings that are implicitly @safe without realizing the
consequences of their actions.
This change introduces a risk to memory safety, extern(C)
declarations that were @system will now be flipped to @safe. No,
putting @system: at the top isn't a solution, extern(C) functions
aren't all nicely put in their own modules. Druntime and Phobos
both have extern(C) declarations throughout their source; I
guarantee you missed them with your PR's trying to illustrate how
simple it is. As others will most definitely miss them as well.
Reasons for Memory Safety:
- Less error prone and simpler for beginners, the default is what
the *correct* behavior should be. They organically discover @safe
writing C bindings.
- Less error prone for advanced users, won't accidentally call a
C function that isn't explicitly verified as being @trusted.
- Switch to @safe by default won't introduce potential security
bugs from extern(C) functions not being annotated @system in the
switch.
- Proven implementation by other safe languages (Rust).
Reasons for Simplicity:
- simpler logic for the compiler
- simpler rules for the user that default to *incorrect* code
- Fear of the unknown, unforeseen complexity
- trust Walter
This is where the divide is, from my perspective. There's this
fear of the unknown, that making it slightly more complicated
will introduce these unforeseen complications that will far
outweigh any benefit that is added from it.
I don't see what that can be. There are other languages that have
safe by default, and then have C declarations be unsafe by
default. They don't have any of these devastation complications
you seem to think that there will be.
This is what doesn't sit right with me. If you could give an
example of a complication that could occur, then I think you
could get more people onboard. But it would have to be
justifiable against the increased security risk of having
extern(C) declarations be @safe by default. For a DIP that is
trying to increase safety, it is a bit ironic that it will also
be reducing safety at the same time.
Otherwise right now, as it stands, this basically boils down to
Logic Vs. Fear.
Please keep in mind that I've made other unpopular decisions
that have proven their worth over time. I hope you'll reserve
judgement until we all see how this change plays out.
If it does turn out badly, it's on me and I'll take my lumps.
You've also done the opposite, you can't justify it with such a
statement unless you've never made a mistake. This whole process
is suppose to avoid exactly this; a single person taking a gamble.
