Code fails with linker error. Why?

[John Colvin via Digitalmars-d-learn]

On Monday, 6 October 2014 at 12:36:41 UTC, ketmar via 
Digitalmars-d-learn wrote:
> On Mon, 06 Oct 2014 11:54:55 +0000
> John Colvin via Digitalmars-d-learn 
> <digitalmars-d-learn at puremagic.com>
> wrote:
>
>> I disagree. It's simple and easy to understand.
> and hackish.

D is very amenable to slightly hackish code.

>> This is the only genuine problem I can see that requires a 
>> language extension. Separating class definition from method 
>> definition in to different compilation units doesn't allow 
>> access to private members without very nasty hacks.

> no hacks needed.

I meant that without a language change, one does need hacks.

> == pkg.classdef.d ==
>   module pkg.classdef;
>   class A {
>   private:
>     int hiddenField;
>     int bar ();
>   }
>
>
> == pkg.othermodule.d ===
>   module pkg.othermodule;
>   import pkg.classdef;
>   // this imlements A.bar() declared in pkg.classdef:
>   @implementation(A) int bar () { return this.hiddenField; }
>
> compiler is perfectly able to put A.bar() implementation in the 
> scope
> of A, and then A.bar can access anything in A. it's the same as
> declaring bar() in class definition.

That would be nice, although personally I'd prefer

int A.bar() { return this.hiddenField; }

as it's less verbose and would be familiar to c++ programmers.