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