On Friday, 29 April 2016 at 10:59:20 UTC, Timon Gehr wrote:
The use case isn't rare (it is a quite popular request, at
least four independent instances that I remember).
Having a mixin in all classes in some subtree of the class
hierarchy can be a good idea. Of course one can easily do it
manually, but it is always nice to get rid of boilerplate.
The argument in favour of this feature is even stronger, it also
impacts correctness.
Both when providing libraries or a large team working within the
same framework.
Programmer 1:
class ComplexAndGenericAbstractBase
{
...
}
Programmer 2:
class Car : ComplexAndGenericAbstractBase
{
... correctly uses mixin
}
Programmer 3:
class BlueCar : Car
{
... no mixin, everything compiles, but is terribly broken at
_runtime_(!)
}
So either P2 needs to remember to prevent anyone from inheriting
from 'Car', or P3 needs to type mixin "out of the blue", P2 might
not even have documented the need to do so, after all the full
doc is in ComplexAndGenericAbstractBase...
