Rationale for accepting DIP 1028 as is

Jonathan M Davis newsgroup.d at jmdavisprog.com
Thu May 28 02:47:01 UTC 2020


On Tuesday, May 26, 2020 8:58:16 PM MDT Andrei Alexandrescu via Digitalmars-d-
announce wrote:
> On 5/26/20 12:31 PM, Bruce Carneal wrote:
> > Currently a machine checked @safe function calling an unannotated extern
> > C routine will error out during compilation. This is great as the C
> > routine was not machine checked, and generally can not be checked.  Post
> > 1028, IIUC, the compilation will go through without complaint.  This
> > seems quite clear.  What am I missing?
>
> If that's the case, it's the death of DIP 1028.

Walter has acknowledged the problem and seems to think that because it's the
programmer's responsibility to deal with extern(C) functions correctly
(since it's not possible for the compiler to do it), it's up to the
programmer to go and fix any existing code that should be marked @system and
isn't and that having the compiler incorrectly mark extern(C) declarations
as @safe isn't a big problem, because programmers need to be spending the
time to check them anyway. He's already created some PRs to try to fix some
issues with extern(C) declarations in druntime and explicitly markingthem as
@system but doesn't seem to think that it's ultimately a big deal.

- Jonathan M Davis





More information about the Digitalmars-d-announce mailing list