SUMMARY
=======

1! No DLL-export support for template instantiations (results in duplicate
   symbols in std.core).

2! /module:reference for std.* modules.

3. Broken std.core.ifc except for native 32-bit toolchain.

4. Dummy/stub std.io.ifc and std.fundamental.ifc.

5. <cstring> in the std.core module.

6. 'export module M;' syntax.


DETAILS
=======


1. No DLL-export support for template instantiations (results in duplicate
   symbols in std.core)
------------------------------------------------------------------------------

The DLL-export support in VC's module machinery does not appear to
recognize/support exported template instantiations in the form (taken from
VC's streambuf header):

template class _CRTIMP2_PURE_IMPORT basic_streambuf<char, char_traits<char> >;

The long version: Here is a reproducing example:

// file: legacy.cxx -*- C++ -*-
#include <iostream>
void f (std::streambuf& sb)
{
  sb.sbumpc ();
}

// file: hello.cxx -*- C++ -*-
import std.core;
void g (std::streambuf& sb)
{
  sb.sbumpc ();
}
int main () {}

cl /std:c++latest /experimental:module /nologo /EHsc /MD /Fo: hello.exe.obj /c /TP hello.cxx
cl /std:c++latest /experimental:module /nologo /EHsc /MD /Fo: legacy.exe.obj /c /TP legacy.cxx
link /NOLOGO /MACHINE:x86 /INCREMENTAL:NO /DEFAULTLIB:shell32.lib /DEFAULTLIB:user32.lib /OUT:hello.exe hello.exe.obj legacy.exe.obj
msvcprt.lib(MSVCP140.dll) : error LNK2005: "public: int __thiscall std::basic_streambuf<char,struct std::char_traits<char> >::sbumpc(void)" (?sbumpc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAEHXZ) already defined in hello.exe.obj

Compare the sbumpc symbol in the two object files:

dumpbin.exe /symbols legacy.exe.obj | grep sbumpc
008 00000000 UNDEF  notype       External     | __imp_?sbumpc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAEHXZ (__declspec(dllimport) public: int __thiscall std::basic_streambuf<char,struct std::char_traits<char> >::sbumpc(void))

dumpbin.exe /symbols hello.exe.obj | grep sbumpc
010 00000000 SECT6  notype ()    External     | ?sbumpc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAEHXZ (public: int __thiscall std::basic_streambuf<char,struct std::char_traits<char> >::sbumpc(void))

This is using the shipped std.core.ifc (though I get identical result with
my custom-built one) using 32-bit 19.11.25505. Note also that I've verified
that _CRTIMP2_PURE_IMPORT in the above statement does indeed expand to
__declspec(dllimport) when compiling my own std.core.ifc.


2! /module:reference for std.* modules.
-------------------------------------------------------------------------------

Currently std.* modules cannot be specified with /module:reference. It would
be useful to be able to do this since /stdIfcPath and IFCPATH make many
assumptions about the directory structure and also expect to find and link
the std.lib library. So it would be useful to be able to specify just the
.ifc file.

For example, with this mechanism I could have easily resolved (4) myself
as a temporary measure.


3. Broken std.core.ifc except for native 32-bit build.
-------------------------------------------------------------------------------

When I try to compile this source file:

  import std.core;
  int main () {std::string s;}

With 15u3 using the x64 command prompt:

  cl.exe /std:c++latest /experimental:module /EHsc /MD /c driver.cxx

I get this error:

  error C2235: mismatching target architecture for compiled module interface
for 'std.core' from 'C:\Program Files (x86)\Microsoft Visual Studio
15.0\VC\Tools\MSVC\19.11.25505\ifc\x64\Release\std.core.ifc'


4. Dummy std.io.ifc and std.fundamental.ifc
-------------------------------------------------------------------------------

It would be helpful to include temporary std.io and std.fundamental packages
that simply re-export std.core. This way one can start writing "portable"
code according to the proposal. I've tried to create my own such modules
and place them into IFCPATH and everything works fine.


5. <cstring> in the std.core module.
-------------------------------------------------------------------------------

It would be helpful if <cstring> was included in std.core (next to <string>).
Having <cstdlib> but not <cstring> seems odd.