D not considered memory safe

[Walter Bright]

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.

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

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.

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

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

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

7. Simple is better.

8. Not needing to learn new things is better.