Programming Languages on Crack
Max Samukha
maxsamukha at gmail.com
Thu Jun 17 09:06:33 UTC 2021
On Thursday, 17 June 2021 at 02:02:58 UTC, Walter Bright wrote:
>
> The idea of putting it at the function level is to force (I
> know,
> that sounds bad, but indulge me for a moment) the programmer
> to think about the decomposition of programs into safe and
> unsafe
> code. Ideally, untrusted code should be encapsulated and
> segregated
> into separate sections of code, with clean, well-defined,
> well-considered,
> and well thought through interfaces.
No, the lambda approach will not lead to those. Just like every
first D project out there abuses "static if" to hack around the
limitations of "version", people will use something like "int a =
() @trusted{ ... terrible hacks... }();" everywhere.
I think you are fighting a strawman here: we are not arguing that
powerful features won't be abused. We are arguing that your
safeguards will not prevent the abuse. By allowing immediately
called nullary lambdas (sematic equivalent of blocks), you are
not forcing people to think about anything but how to hack around
the lack of trusted blocks.
I could play an experience card too, and say that the shittiest
code I have ever seen was written to work around programming
language limitations. So, your argument works both ways: yes,
powerful features may and do lead to shitty code, and, yes,
limitations may and do lead to shitty code.
More information about the Digitalmars-d
mailing list