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

On 03/28/2018 01:34 AM, arturg wrote:
> you can call them with __traits(getOverloads, T, "name")[index];
> 
> you can overload on types attributes and linkage, but seems like you can only merge overloads based on types.

I don't think there's value in allowing overloads that can only be called via __traits.

Looks like this is an old issue [1] that is currently being fixed. run.dlang.io's "beta" and "nightly" compilers don't accept such overloads [2]. But I can't reproduce that locally. The fix has apparently been reverted because it needs more work.


[1] https://issues.dlang.org/show_bug.cgi?id=2789
[2] https://run.dlang.io/is/qlyMti

On Tuesday, 27 March 2018 at 21:02:11 UTC, 12345swordy wrote:
> On Tuesday, 27 March 2018 at 20:49:25 UTC, ag0aep6g wrote:
>> On 03/27/2018 10:39 PM, 12345swordy wrote:
>>> class A
>>> {
>>>      @recursive @safe void talk()
>> [...]
>>> }
>>> class B : A
>>> {
>>>      override void talk() // @safe attribute added by recursive attribute and can not be removed
>> [...]
>>> }
>>
>> It already works like that. B.talk is @safe, and you can't make it @system. You can mark it as @system, that gets overridden by A.talk's @safe.
>>
>> https://run.dlang.io/is/BlH8bp
> Then explain this then.
> https://run.dlang.io/is/S2KLs5

Your actual test should have been like this:

https://run.dlang.io/is/nF9dQk

And as you can see it gives an error.

You wouldn't be able to do anything that's not safe, so it wouldn't really matter.

As soon as you attempted to do something else the compiler would yield an error.