Greenwashing: best practices
Johannes T
isrvoid at gmail.com
Sun May 31 10:35:49 UTC 2020
On Saturday, 30 May 2020 at 22:00:27 UTC, Paul Backus wrote:
> [..]
> If a particular version of a particular implementation on a
> particular platform has a bug, well, that's the
> implementation's problem, not yours. You can't possibly vet
> every version of `recv` that your code could ever be linked
> with (especially because some of those versions may not even
> exist at the time you do the vetting!).
> [..]
That's a good point. Also, when an issue is discovered in a newer
release, changing back to @system wouldn't be a sensible path.
The safety of the interface should govern the attribute. I didn't
realize that.
> [..]
> As far as I know there's no advantage to using a .di file over
> a regular .d file for C bindings.
> [..]
You're right, .di shouldn't cause contention. Use whatever is
more consistent.
> [..]
> On the other hand, you could *also* just write the whole thing
> as @system, and leave migrating to @safe for later--at which
> point the compiler will bug you about your C function calls,
> and you can take the time to fix them *properly*. This has the
> advantage that you never give yourself a false sense of
> security by pretending code is @safe when it actually isn't.
I hope Nick Treleaven's great idea with `@safe module foo;` will
gain traction. It would make the migration path more convenient.
Thanks!
More information about the Digitalmars-d
mailing list