D Language Foundation April 2024 Monthly Meeting Summary

[Jonathan M Davis]

On Wednesday, July 31, 2024 12:50:39 PM MDT Dukc via Digitalmars-d-announce 
wrote:
> Jonathan M Davis kirjoitti 31.7.2024 klo 19.00:
> > The problem with slicing static arrays does exist without DIP 1000, but
> > that can be solved by actually treating it as @system like it should be
> > (since it's basically just a different syntax for taking the address of a
> > local variable for a specific type of variable). Removing implicit
> > slicing of static arrays also improves the situation since then you don't
> > get surprises where you're doing something @system without realizing it.
> > DIP 1000 is not required to solve that problem.
>
> We also need to disable taking a pointer of a struct field, if that
> struct is local or `ref` (including the `this` `ref`). But adding that,
> yes, works. This is exactly what Robert proposed at last DConf. I'm
> going to call his proposal Simple Safe D as per the title of the talk.
>
> It would keep the language as simple as it's without DIP1000 and would
> be memory safe, but it would break existing code just as hard as DIP1000
> does. Plus, nothing in DIP1000 forces you to use it's extra features
> compared to Simple Safe D. You can avoid the compiler complaining by
> simply using the GC either way.

Not really, since with DIP 1000, the compiler infers scope in some cases,
and then you're forced to deal with it whether you like it or not. Even
though I don't normally use DIP 1000, I've found that in the cases where
I've tried, I inevitably get cryptic complaints that I have to figure out
how to fix with regards to scope (which is particularly annoying with
templated code).

Either way, my big problem with DIP 1000 is simply that it adds a ton of
complexity to the language, and if that complexity is there, I'm going to
have to deal with it at some point unless I'm only writing code for myself
and never interact with anyone else's code (which obviously isn't realistic,
especially if I use D professionally). I don't believe that that complexity
pays for itself, and honestly, if it becomes the default, I'm going to be
tempted to just slap @system on everything and give up on @safe entirely,
because I simply don't want to deal with it - but even then, that won't work
when dealing with code that I don't write.

- Jonathan M Davis