Greenwashing

welkam wwwelkam at gmail.com
Thu May 28 11:26:04 UTC 2020


On Thursday, 28 May 2020 at 09:33:26 UTC, Walter Bright wrote:
> On 5/27/2020 5:31 PM, Jonathan M Davis wrote:
>>  since he won't listen
>
> More accurately "does not agree".

1. D`s @safe is not powerful enough to be used with manual memory 
management.
2. Because of 1 people dont see enough value in using @safe in 
their code especially if it interfaces with C libraries.
3. Because of 2 when @safe becomes default, people will use the 
least effort required way to shut up the compiler. Meaning @safe: 
at top level of a module.
4. Because of 3 you think compiler should mark extern C functions 
as safe by default.

Most of the talks in this forum focused on 4. I think people 
missed the forest for the trees. The real problem is 1. As long 
as there are no way to mechanically verify use of malloc and free 
to be safe, or at least wrap in easy to use safe constructs, I 
dont see any way how DIP 1028 can be changed to not be 
problematic. As long as @safe is not useful enough all potential 
outcomes of DIP 1028 are bad.

But I am just random guy on the internet.


More information about the Digitalmars-d mailing list