On Fri, Aug 3, 2018 at 7:22 PM Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 03.08.2018 at 19:08, Pedro Magalhães wrote: > > What currently happens is that (like with normal methods), the method on > > the receiving class is used and the method from the trait is simply > ignored. > > Yes. However, if the class using the trait would not implement the > method, a compile time error would be thrown. > Not really, I mean, the error you get is that you are declaring an abstract method in a non abstract class. If the receiving class is abstract, this works as expected (https://3v4l.org/QdHBo) and nothing is imposed on the receiving class. I think this is also what Levi is referring to. (Correct me if I'm wrong) > > Although this can be fixed, I wanted your opinion on it as this would be > > the only thing from traits that would impose anything on the receiving > > class and conflicts with the normal precedence rules. > > Frankly, I don't understand what this bug report is about, > <https://3v4l.org/38lmA> looks pretty much expected (note that the error > message is totally different from what has been reported; there is no > class D in the reproduce script). > Yes, the report is not very clear. But if we follow the docs logic, A::values in your example should fail to compile as it doesn't have the same signature (return type) as the method from the trait T. Regards, Pedro
