DIP1028 - Rationale for accepting as is

[Jonathan M Davis]

On Wednesday, May 27, 2020 6:24:25 PM MDT Andrei Alexandrescu via Digitalmars-
d-announce wrote:
> On 5/27/20 9:42 AM, Andrej Mitrovic wrote:
> > On Wednesday, 27 May 2020 at 09:50:50 UTC, Walter Bright wrote:
> >> Un-annotated C declarations should be a red flag to any competent QA
> >> team. Recognizing a false @trusted is a whole lot harder.
> >
> > Is the actual problem those `@trusted:` declarations at the top of C
> > headers?
> >
> > There could be a simple solution to that:
> >
> > Ban `@trusted:` and `@trusted { }` which apply to multiple symbols. Only
>
> > allow `@trusted` to apply to a single symbol. For example:
>
> Oh wow what an interesting idea. Thanks.

I've argued for years that mass-applying any attribute is bad practice. It
makes it way too easy to accidentally apply an attribute to a function, and
experience has shown that it makes it _far_ easier to not realize that a
funtion already has a particular attribute (it's definitely happened in
Phobos PRs that an attribute has been mass-applied and then someone comes
along later and applies it to a specific function, because they didn't think
that that function had that attribute). Unfortunately, plenty of people seem
to love to mass apply attributes rather than marking each function
individually (presumably, because they hate having to use attributes all
over the place). And regardless of whether DIP 1028 is a good idea as-is,
the sad reality of the matter is that it's not uncommon even in druntime for
someone to slap @trusted: at the top of a module. It implies that the
declarations in question were not actually checked, and it's incredibly
error-prone when new declarations are added.

Personally, I normally only use : with access-level modifiers, and while I
like doing that (especially since I think that public and private functions
should normally be segregated anyway), I'm increasingly coming closer to the
conclusion that it's actually a bad idea in practice, because it's not
uncommon for people to not know which access-level modifier applies -
especially when looking at diffs in PRs.

I would _love_ to see it become illegal to mass-apply @trusted (or even
attributes in general), but I have no clue how easy it would be to get such
a DIP accepted or how much screaming there would be over it if it were
actually accepted.

- Jonathan M Davis