Why do abstract class functions require definitions?

[Marc Schütz via Digitalmars-d-learn]

On Wednesday, 16 September 2015 at 09:31:25 UTC, Jacob Carlborg 
wrote:
> On 2015-09-16 10:49, FiveNights wrote:
>> Every so often I'll get a compiler error that isn't 
>> particularly clear
>> on what's wrong and eventually I'll figure out that what's 
>> causing it is
>> having a function in an abstract class somewhere that isn't 
>> defined:
>>
>> abstract class SomeClass {
>>      int someVariable;
>>      void someFunction();
>> }
>> the solution is usually:
>> void someFunction(){}
>>
>> Usually the abstract class is a converted interface, but it 
>> turned out
>> that I needed to include a variable for it to work out and I 
>> just wasn't
>> keen on remembering to put a mixin in each derived class.
>>
>> I'm just wondering why I can't have an undefined function in 
>> an abstract
>> class? I'd the compiler to say, "Hey, you forgot to put 
>> 'someFunction()'
>> in 'SomeDerrivedClass', go do something about that." when I 
>> end a
>> function with a semi-colon in the base class and don't have it 
>> in the
>> derrived. Everything just seems to break in cryptic ways 
>> unless I curly
>> brace the function ending.
>
> I'm guessing you see a link error. The reason you see that 
> instead of a compile error is because D supports separate 
> compilation. Meaning that the method could be implemented in a 
> different library that are resolved during link time.
>
> As already answered in another post, the solution is to prefix 
> the method declaration with "abstract".

Wouldn't the following behaviour be more useful as a default?

     abstract class Foo {
         void bar1() { }     // non-abstract, obviously
         void bar2();        // abstract, because it's in an 
abstract class
                             // (different from now)
         extern void bar3(); // non-abstract, but defined 
externally
     }