http://d.puremagic.com/issues/show_bug.cgi?id=4542

           Summary: TDPL NVI example results in linker error
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: epi@atari8.info


--- Comment #0 from Adrian Matoga <epi@atari8.info> 2010-07-31 16:00:54 PDT ---
Trying an example from TDPL (p. 214) results in linker error.

Source:

import std.stdio;

interface Transmogrifier
{
    final void thereAndBack()
    {
        transmogrify();
        untransmogrify();
    }

private:
    void transmogrify();
    void untransmogrify();
}

class CardBoardBox : Transmogrifier
{
    override private void transmogrify()
    {
        writeln("transmogrify");
    }

    override private void untransmogrify()
    {
        writeln("untransmogrify");
    }
}

void main()
{
    (new CardBoardBox).thereAndBack();
}


Linker output:
OPTLINK (R) for Win32  Release 8.00.2
Copyright (C) Digital Mars 1989-2009  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
impl.obj(impl)
 Error 42: Symbol Undefined _D4impl14Transmogrifier12transmogrifyMFZv
impl.obj(impl)
 Error 42: Symbol Undefined _D4impl14Transmogrifier14untransmogrifyMFZv
--- errorlevel 2


The same issue occurs, when private is replaced with package. protected and public do work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Christian Kamm <kamm-removethis@incasoftware.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kamm-removethis@incasoftwar
                   |                            |e.de


--- Comment #1 from Christian Kamm <kamm-removethis@incasoftware.de> 2010-07-31 23:11:05 PDT ---
This happens since private and package methods in D are implicitly final and thus cannot be overridden. I'm not sure whether it is a genuine bug in TDPL or just foreshadows to a planned change in dmd and the spec that hasn't been applied yet.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Jonathan M Davis <jmdavisProg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmail.com


--- Comment #2 from Jonathan M Davis <jmdavisProg@gmail.com> 2010-08-11 10:13:06 PDT ---
NVI is a highly useful idiom, and generally-speaking, dmd is supposed to come in line with TDPL rather than TDPL being in error. So, I'd definitely argue that the access level should have nothing to do with the overridability of a function, regardless of what was originally intended for D. We have final if we want to make functions non-overridable. There's no need to overload access level to make it do the same thing. I'd say that dmd and the spec should come in line with TDPL in this case.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei@metalanguage.com
         AssignedTo|nobody@puremagic.com        |andrei@metalanguage.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|andrei@metalanguage.com     |bugzilla@digitalmars.com


--- Comment #3 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-01-16 15:21:22 PST ---
Reassigning to Walter - this is a compiler issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86_64                      |x86


--- Comment #4 from Brad Roberts <braddr@puremagic.com> 2011-02-06 15:39:29 PST ---
Mass migration of bugs marked as x86-64 to just x86.  The platform run on isn't what's relevant, it's if the app is a 32 or 64 bit app.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #5 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-03-01 17:40:31 PST ---
I'm going to chime in on this to say that I definitely recant what I said previously on this. I do _not_ think that TDPL is correct in this case. After having discussed it on the newsgroup previously, it was shown that you could do NVI with protected just fine and that using private for that doesn't actually buy you anything. However, if we make private overridable, then all of a sudden the default case for private is virtual and thus non-inlineable, which will definitely have a negative effect on performance. It _is_ possible to mark a private function as final to make it non-virtual and thus inlineable, but that means that if you want efficient private functions, you're going to have to get in the habit of specifically marking all of your private functions as final - just so that NVI can be done with private instead of protected in spite of the fact that protected does the job just fine.

So, making private overridable makes the default case inefficient for essentially no gain.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #6 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-09-08 18:53:20 PDT ---
(In reply to comment #5)
> but that
> means that if you want efficient private functions, you're going to have to get
> in the habit of specifically marking all of your private functions as final

Can't the compiler determine this automatically?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-09-08 19:15:21 PDT ---
(In reply to comment 6)
> Can't the compiler determine this automatically?

No. In order to do that, it would have to know about every single class in the program that's derived from that class - directly or indirectly. That can't be known before linking. And by then, the function is already virtual or not. The compiler can only make a class' member function non-virtual when it can _know_ that no virtual calls to that function will ever be made. And that's can't generally be known. final guarantees it. I'm not sure that there's any other case when the compiler can determine it. Best case, there are some situations where it can know that a particular call doesn't need to be virtual. e.g. In

(new A()).func()

func could be done non-virtually by the compiler if it chose to optimize the code that way, because it can _know_ the exact type of A and avoid the virtual call (I don't know if it does). However, you can't even do that sort of optimization very often if you don't do flow analysis, which dmd typically avoids.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4542



--- Comment #8 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-09-08 19:21:38 PDT ---
Well in any case, unless you interleave your private and public functions, you can use a shortcut:

class Foo
{
    final:

    private void x() {}
    private void y() {}
}

Has to be done for every class though, so maybe that's too much work..

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------