class X
{
final: // <- naturally, this is the first line in any D class
...
abstract void f(); // <- error, can't be abstract and final!
}
I think abstract should override final in this case, and not be an error...?
Without the ability to do this, you have to use final { ... }, and have little blocks littered throughout classes, which is really unpleasant. That causes an extra indentation level, making it hard to follow; class members look like they're in a function because they're indented an extra level.
Comment #1 by lt.infiltrator — 2015-12-01T02:31:08Z
I don't know whether I agree with your statement "naturally, this is the first line in any D class", but I agree that final: and abstract: should override each other as public:, protected:, etc. do.
I assume that you are currently working around this buy having all of your abstracts up the top before your final: line?
Comment #2 by turkeyman — 2015-12-01T08:06:06Z
(In reply to Infiltrator from comment #1)
> I don't know whether I agree with your statement "naturally, this is the
> first line in any D class", but I agree that final: and abstract: should
> override each other as public:, protected:, etc. do.
>
> I assume that you are currently working around this buy having all of your
> abstracts up the top before your final: line?
Yeah. It's fine for now, it's just a awkward.
In this case, the D class is an extern(C++) mirror of the C class, which means if I rearrange the virtual functions, the vtables no longer match. Obviously I have to take care to not rearrange the order of the virtuals, but it's harder to prove this when I can no longer diff the C++ and D code (which are almost identical in terms of lines). Since the D class must be rearranged, it's much harder to compare it to the C++ version, and I don't see a good reason for that nuisance.
Of course, the common case is that 'final:' appear at the top of every class, for reasons that I'm trying to stop repeating ;)
Comment #3 by lt.infiltrator — 2015-12-02T15:55:46Z
(In reply to Manu from comment #2)
> Yeah. It's fine for now, it's just a awkward.
>
> In this case, the D class is an extern(C++) mirror of the C class, which
> means if I rearrange the virtual functions, the vtables no longer match.
> Obviously I have to take care to not rearrange the order of the virtuals,
> but it's harder to prove this when I can no longer diff the C++ and D code
> (which are almost identical in terms of lines). Since the D class must be
> rearranged, it's much harder to compare it to the C++ version, and I don't
> see a good reason for that nuisance.
The workaround is to just not use ":". Just abstract or final each function as you go. It's not pretty; and gets annoying; but if you care about diffing, then it's your best bet for now, I think.
Comment #4 by robert.schadek — 2024-12-13T18:45:56Z