Removing swiftMSVCRT - is a migration path useful?

The Swift SDK overlay on Windows currently has

  • ucrt (clang module)
  • visualc (clang module)
  • MSVCRT (swift module)

The MSVCRT module on Windows was never well understood by most. The structure was actually very simple IMO: ucrt is the C library defined by a modulemap, the visualc module was a small module that bridged some portions of MSVCRT (which are largely uninteresting and increasingly unnecessary). The MSVCRT Swift module basically re-exported both, ucrt and visualc, modules and added the conveniences like type generic math routines. This was only useful if those conveniences were explicitly required, otherwise, importing ucrt was sufficient to gain access to most things.

The Windows installation currently requires installation of 4 support files, of which 2 are files for the visualc module (the modulemap and apinotes). Additionally, use of Swift requires the installation of the Visual Studio IDE or build tools as the VIsual C module is only available through that. In reality, pieces that the Visual C module provides are stdint.h, setjmp.h, and vadefs.h (the VCRT equivalent to stdarg.h). When using Swift, these are actually provided by clang and the only dependency is on the SDK and ucrt, both of which are available as part of the standalone SDK installer or part of Visual Studio.

The removal of visualc means that the swiftMSVCRT is now even a larger misnomer and will be even more confusing for users. I am tempted to simply replace the MSVCRT SDK overlay component and replace it with another module. As much as I would've liked to just make the module ucrt, the shadowing seems to cause dependency issues as the module loading seems to confuse the clang and Swift modules.

The question is - given that Windows does not declare a stable interface yet, is a migration path important enough to provide or does it make more sense to simply sweep away the cruft and pretend that it never existed? Replacing any instance of import MSVCRT with import CRT would be the manual migration path, rather than providing a compatibility shim which would allow the older code to continue working without changes.

CC: @Douglas_Gregor @Mike_Ash


I don't feel informed enough about Windows to have a good opinion on this. My impression is that we're not yet at a point where having a migration path is important. Your blog post mentions "early adopters" and that seems like the sort of situation where it's OK to change things around without preserving total source compatibility. I would defer to your wisdom, though.


That's good idea to get rid of Visual Studio dependency. Changing a few imports in our project seems a reasonable price for better and cleaner module structure. We're using swift dev branch, therefore always expecting the unexpected.