DIP1028 - Rationale for accepting as is

Bruce Carneal bcarneal at gmail.com
Wed May 27 14:55:36 UTC 2020


On Friday, 22 May 2020 at 01:22:19 UTC, Walter Bright wrote:
> I have made these points before, but I'll summarize them here
> for convenient referral.
>
  [big snip of very long and arguably tangential Java screw-up and 
other]

> How does this relate to safe by default?
>
> Consider the common (because that's how D started out) case of:
>
> ----- clibrary.d --------
>
>     T massage_data(... many parameters ...);
>     ... 200 more such declarations ...
>
> ----- app.d ----------
>
>     import clibrary;
>
>     void useClibrary( ... parameters ...) {
>         massage_data(parameters);
>     }
>
> ---------------------
>
> This code, today, does not use annotations and it works. It's 
> been working
> for a long time. Now, we implement the amendment, and it stops 
> compiling
> because useClibrary is @safe and massage_data is @system. The 
> user is faced
> with the following alternatives:
>
> 1. Go through 200 functions in clibrary.d and determine which 
> are @safe
> and which are @system. This is what we want them to do. We try 
> to motivate
> this with compiler error messages. Unfortunately, this is both 
> tedious and
> thoroughly impractical, as our poor user Will Not Know which 
> are safe and
> which are system. We can correctly annotate core.stdc.stdio 
> because I know
> those functions intimately. This is not true for other system C 
> APIs, and
> even less true for some third party C library we're trying to 
> interface to.

So, to condense and hopefully clarify: we can not use option 1) 
and @system by default because "our poor user Will Not Know which 
are safe and which are system"?
IOW, because someone unable to comment on safety would be 
inconvenienced we enable them to inject more code into the 
ecosphere by making @safe the default.

What am I missing?

>
> 2. Annotate useClibrary() as @trusted or @system. While easier, 
> this causes
> all benefits to @safe by default to be lost.
>
> 3. Wrap the call to massage_data() with:
>
>     () @trusted { massage_data(parameters); } ();
>
> If there are a lot of calls to clibrary, this is going to look 
> pretty awful.
> Nobody likes writing or reading such ugly code. It's ok here 
> and there, but
> not as a general thing.
>
> 4. Edit clibrary.d and make the first line:
>
>     @safe:
>
[snip regarding greenwashing and other]




More information about the Digitalmars-d-announce mailing list