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