Recursive attribute for virtual functions?

[Jonathan M Davis]

On Tuesday, March 27, 2018 21:10:25 12345swordy via Digitalmars-d wrote:
> On Tuesday, 27 March 2018 at 21:05:32 UTC, ag0aep6g wrote:
> > On 03/27/2018 11:02 PM, 12345swordy wrote:
> >> Then explain this then.
> >> https://run.dlang.io/is/S2KLs5
> >
> > B.talk is @safe. The compiler ignores the @system attribute on
> > B.talk, because A.talk's @safe attribute takes precedence.
>
> Shouldn't it give a warning then?

Warnings are almost always a terrible idea, since it's bad practice to leave
warnings in place, meaning that it's effectively the same as an error except
that it doesn't force folks to fix the problem immediately, and thanks to
-w, it effectively forks the language, because stuff like is expressions and
which template constraints pass or not can change based on whether -w is
used or not. IMHO, it was a huge mistake to ever add warnings to the
compiler. So, if we were going to do something with this, it should be an
error, not a warning.

In most cases, D ignores attributes that don't apply, which is sometimes
annoying, but it can be very handy in generic code. It can also be helpful
when an attribute is applied with : or {}. So, it's not particularly
surprising that the compiler would ignore the attribute in this case. That
being said, at the moment, I can't think of any reason why it would be
beneficial to allow marking a derived function with @system directly when
the base class function is @safe. Marking it with @trusted is often
valuable, because in that case, the derived function is doing something
that's @system, but the programmer has validated that it's @safe, so it
doesn't violate the API of the base class. So, you wouldn't want to treat it
like you would a function that was directly marked with @safe @trusted, but
that doesn't mean that @system couldn't be disallowed.

- Jonathan M Davis