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.

declare as
abstract void someFunction();

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".

-- 
/Jacob Carlborg

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
    }

On 9/16/15 6:36 AM, Marc Schütz wrote:

> 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
>      }


My guess is that .di files need the bar2 syntax style.

-Steve

On 2015-09-16 12:36, Marc Schütz wrote:

> 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
>      }

Currently "extern" has the meaning, at least on Windows, that the symbol will be visible outside a dynamic library.

-- 
/Jacob Carlborg

On Friday, 18 September 2015 at 13:18:23 UTC, Jacob Carlborg wrote:
> On 2015-09-16 12:36, Marc Schütz wrote:
>
>> 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
>>      }
>
> Currently "extern" has the meaning, at least on Windows, that the symbol will be visible outside a dynamic library.

That's `export`.

On 2015-09-18 17:45, Jakob Ovrum wrote:

> That's `export`.

Right, my bad. D has too many attributes :)

-- 
/Jacob Carlborg