Code fails with linker error. Why?

[John Colvin via Digitalmars-d-learn]

On Monday, 6 October 2014 at 10:10:04 UTC, eles wrote:
> On Saturday, 4 October 2014 at 15:29:57 UTC, John Colvin wrote:
>> On Saturday, 4 October 2014 at 11:19:52 UTC, ketmar via 
>> Digitalmars-d-learn wrote:
>>> On Sat, 04 Oct 2014 11:01:28 +0000
>>> John Colvin via Digitalmars-d-learn 
>>> <digitalmars-d-learn at puremagic.com>
>>> wrote:
>>>
>>>> On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via 
>>>> Digitalmars-d-learn wrote:
>>>> > On Sat, 04 Oct 2014 10:27:16 +0000
>>>> > John Colvin via Digitalmars-d-learn 
>>>> > <digitalmars-d-learn at puremagic.com>
>>>> > wrote:
>
>> I don't really see the point though.
>>
>> class A
>> {
>>    void foo(int a) { Afoo(this, a); }
>> }
>>
>> then declare and define Afoo however you like.
>
> That's hackish, bad and convoluted.

I disagree. It's simple and easy to understand.

> And it does not/should not allow one to mess with the private 
> fields of the class, especially if Afoo is defined in another 
> module.

s/especially/only

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.

> And on that matter, a function that is to be provided by 
> another module should be explicitly marked as such in its 
> declaration.
>
> Otherwise, I could declare a function, forget to provide its 
> definition, still having the surprise that the code compiles 
> and runs with very strange results because some other module 
> provides a function that just happens to work.

I don't quite follow. Example?

> Let's not even say how messy this could get with version() 
> where you could disable a function definition by error, in one 
> version, but still have a software that compiles and runs 
> nowhere.