D not considered memory safe

[Timon Gehr]

On 7/25/24 04:32, Walter Bright wrote:
> On 7/22/2024 12:00 PM, Timon Gehr wrote:
>> Anyway, the point is there should be a way to have the compiler help 
>> you do this kind of safety scaffolding without you needing to lie to 
>> the compiler.
> 
> I understand your design and it has merit.
> 
> Issues:
> 
> 1. the proliferation of these features. Have you seen all the C 
> extensions VC and gcc have? It makes for an excessively large and 
> intimidating language. The larger the specification, the less people 
> will read it.
> ...

Hardly applies in any relevant fashion to pragmas that enable additional 
type checking.

> 2. if an existing feature can be pressed into service instead, adding a 
> new feature needs a big advantage
> ...

You are in effect removing an existing feature.

> 3. one of the earliest goals with D was to make it easier for managers 
> and QA staff to have rules and enforce them. @trusted was always 
> intended to be an easily greppable construct so that the QA reviewer 
> knows where to focus his effort. A manager can lay down a rule "no 
> level1 programmers can check in @trusted" and enforce it mechanically.
> ...

Well, your approach is essentially that your higher-level programmers go 
around slapping `@trusted:` on files. I'll give you that banning "level1 
programmers" from checking in any code at all probably does help safety.

> 4. @trusted makes for a nice and easily grepped TODO list to measure 
> progress on making the code actually safe
> ...

No, some uses of `@trusted` are inevitable. `@trusted` means: "this has 
been audited and the author certifies that the interface is safe".

What you are describing is not `@trusted`, you are describing `@yolo`: 
"this has not been audited at all but I need it to be `@safe` anyway for 
marketing purposes".

> 5. In a final release, @trusted should be quite rare. But it's up to the 
> team to enforce it.
> ...

Well, what do you think I am doing here? You are behaving in a way I 
deem irresponsible by promoting this way of using `@trusted`.

> 6. @trusted can absolutely be abused. But you can't hide it!
> ...

I am putting forward a critique of that abuse, which is indeed plainly 
visible.

> 7. Simple is better.
> ...

Apparently `@trusted` is already too complex for most people to wrap 
their heads around it. It's a pity.

> 8. Not needing to learn new things is better.

The way you suggest `@trusted` should be used is a novelty. It's a 
completely new attribute.