(this is about DDMD internals, but the DMD-internals forum is maillist only, so posting here. Pardon me please. [*] )

Currently some functions are defined (as opposed to declared) both in C++ and in D. For example, all of Visitor's virtual methods. The "double-defined" methods are all defined such that C++ should inline them (C++ spec), but it is causing trouble with MSVC (who does not inline as much in debug mode it seems, even when explicitly telling it to be spec compliant).
This is causing troubles when building LDC, using MSVC+LDC (using LDC as the D-compiler to build itself, instead of DMD who creates object files with a more lax linking attribute on all symbols). Symbols show up in D-object files and C++-object files and the MSVC linker does not want to link ldc2.exe. We can work around this... but I'd rather not increase the diff with upstream...

Regardless of LDC's troubles, do we really want methods to be double-defined? Is this intentional, or perhaps a remnant of semi-automated C++->D conversion? I doubt that the extra inlining possibilities are noticable (but I did not measure).

Shall I work on a PR that removes (some of) the double-defined guys from C++ source?
(read: would that have a chance of pulling without long debate)

Thanks,
  Johan


[*] Perhaps add a "DMD" section under "Ecosystem"?

On 8/03/2016 7:12 AM, Johan Engelen wrote:
>  or perhaps a remnant of
> semi-automated C++->D conversion?

That.

On 3/7/2016 2:19 PM, Daniel Murphy wrote:
> That.

Daniel is a man of few words :-)

On Monday, 7 March 2016 at 22:19:46 UTC, Daniel Murphy wrote:
> On 8/03/2016 7:12 AM, Johan Engelen wrote:
>>  or perhaps a remnant of
>> semi-automated C++->D conversion?
>
> That.

:)
Out with it, then?

On 8/03/2016 8:42 PM, Johan Engelen wrote:
> On Monday, 7 March 2016 at 22:19:46 UTC, Daniel Murphy wrote:
>> On 8/03/2016 7:12 AM, Johan Engelen wrote:
>>>  or perhaps a remnant of
>>> semi-automated C++->D conversion?
>>
>> That.
>
> :)
> Out with it, then?

If it still links.  Vtbl emission can be tricky.