Microsoft announces to open source MSVC’s STL

Microsoft announced the open-source implementation of the C++ Standard Library (STL), source code hosted on GitHub, using the Apache License v2.0 with LLVM Exceptions license. Microsoft said that it chose this license to facilitate the libc++ project to share code with MSVC’s STL. However, the two projects are not merged at present, and still support different libraries of different platforms, with different data structure representations.

Our primary goals are conformance, performance, usability, and compatibility.

• Conformance: The Working Paper is a moving target; as features and LWG issue resolutions are added, we need to implement them. That can involve a lot of work, because the STL is required to behave in very specific ways and to handle users doing very unusual things.
• Performance: The STL needs to be extremely fast at runtime; speed is one of C++’s core strengths, and most C++ programs use the STL extensively. As a result, we spend more time on optimization than most general-purpose libraries. (However, we’re wary of changes that improve some scenarios at the expense of others, or changes that make code significantly more complicated and fragile. That is, there’s a “complexity budget” that must be spent carefully.)
• Usability: This includes parts of the programming experience like compiler throughput, diagnostic messages, and debugging checks. For example, we’ve extensively marked the STL with [[nodiscard]] attributes because this helps programmers avoid bugs.
• Compatibility: This includes binary compatibility and source compatibility. We’re keeping VS 2019 binary-compatible with VS 2017 and VS 2015, which restricts what we can change in VS 2019 updates. (We’ve found that significant changes are possible even though other changes are impossible, which we’ll be documenting in our Contribution Guidelines soon.) While there are a few exceptions to this rule (e.g. if a feature is added to the Working Paper, we implement it, and then the feature is significantly changed before the International Standard is finalized, we reserve the right to break binary compatibility because /std:c++latest offers an experimental preview of such features), binary compatibility generally overrides all other considerations, even conformance. Source compatibility refers to being able to successfully recompile user code without changes. We consider source compatibility to be important, but not all-important; breaking source compatibility can be an acceptable cost, if done for the right reasons in the right way (e.g. in a controlled manner with escape hatches).