Microsoft Wants To Add DirectX + HLSL Support To The Upstream LLVM/Clang Compiler

[Old Nobody]

Whatever Microsoft does: I can't forget that they're following the "Embrace, extend, and extinguish" (EEE) strategy, very popular among the big commercial players.
"Embrace" was WSL and the buy of Github. They're in the "extend" phase now. Alphabet, Amazon and Meta are in "extinguish" in their areas.

[ⲣⲂaggins]

Whatever Microsoft does: I can't forget that they're following the "Embrace, extend, and extinguish" (EEE) strategy, very popular among the big commercial players.

Seems more like EEE in reverse. "Here's an open-source compiler for a language we previously used as vendor lock-in."

[mSparks]

Strongly agree. Independent companies, no matter how big they are just can't keep up.

It would be nice to weaponize this fact a little more. For example:

"No Microsoft, you will have to maintain your HLSL stuff out of tree because you consistently demonstrate that you are a bunch o' nobs"

Same with Intel and their potential "pay as you go" hardware activation. Sure this has existed in various forms for a while but the open-source community should be making it as hard as possible for them rather than giving them the convenience of it residing in the upstream kernel tree.

Glad Im not the only one who has noticed.

There are some caveats, such as in certain highly specialist areas that require a lot of investment like graphics and aviation that are pretty sticky.

But just how far ahead vast numbers of gpl programs have gotten over their closed source competition seemed untenable even just 5 years ago.

[Smurphy]

Well, as it would be in LLVM and presumably maintained by MS themselves, it could be used by anyone, including DXVK and Mesa. It would still require some work, but could be more compatible that the current solutions, or at least have different bugs.

This just reminds me of Microsoft constantly adding a new UI on a rotten base.
I prefer something simple and clean, not controlled by a corporation - especially not Microsoft, Apple or Google!

[khanich]

I think Microsoft will eventually deprecate MSVC and fully embrace LLVM.

Considering that Microsoft is these days leading in implementing new C++ feature first, I doubt that.

MSVC already has implemented all C++20 features (the same goes for Microsoft's standard library implementation).
Both, GCC and Clang, are nowhere near, yet.

A few example of big features that aren't implemented (and declared stable) yet:
- formatting (std::format)
- <=> support in the standard library
- std::stop_token and std::jthread
- "The One Ranges Proposal"
- Calendar and timezone
- modules
- coroutines
(If you want to read into it: https://en.cppreference.com/w/cpp/compiler_support)
Heck, GCC is faster than Clang too.

[dragon321]

Considering that Microsoft is these days leading in implementing new C++ feature first, I doubt that.

MSVC already has implemented all C++20 features (the same goes for Microsoft's standard library implementation).
Both, GCC and Clang, are nowhere near, yet.

A few example of big features that aren't implemented (and declared stable) yet:
- formatting (std::format)
- <=> support in the standard library
- std::stop_token and std::jthread
- "The One Ranges Proposal"
- Calendar and timezone
- modules
- coroutines
(If you want to read into it: https://en.cppreference.com/w/cpp/compiler_support)
Heck, GCC is faster than Clang too.

Actually the page you mentioned states that GCC has near complete support for C++20 features. The only thing that is only partially implemented is modules, rest are fully supported. As goes for standard library most C++20 features are supported as well. Only few are supported partially or not yet supported. Clang support for C++20 is worse than GCC but not very much, most features are implemented as well.

Yes, it's true that MSVC currently supports all C++20 features but I wouldn't call GCC or Clang support "nowhere near". Both have almost complete support for this standard and only few things are missing or partially implemented.

[khanich]

Actually the page you mentioned states that GCC has near complete support for C++20 features. The only thing that is only partially implemented is modules, rest are fully supported. As goes for standard library most C++20 features are supported as well. Only few are supported partially or not yet supported. Clang support for C++20 is worse than GCC but not very much, most features are implemented as well.

Yes, it's true that MSVC currently supports all C++20 features but I wouldn't call GCC or Clang support "nowhere near". Both have almost complete support for this standard and only few things are missing or partially implemented.

Well, I consider Compiler and standard library as one package since they depend on each other (for example look at coroutines or std::initializer_list).

About partial features: the site doesn't tell you how far the implementation is. Is it 10% completed? Is it 90% completed? Both are considered partial.

If we go by amount of features, yes, they are pretty close, but if we go about the sizes of the features, no, they aren't yet.

Modules, "The One Ranges Proposal" and text formatting are all parts which are pretty big.
In case you don't know, here a very simplified explanation of these:

• Modules has to do with you you import libraries (no #include anymore for these, although you can also use them as a complete header replacement which some people are going to do).
• "The One Ranges Proposal" essentially goes and replaces iterators (pairs) and allows lazy computation of values (you can essentially pipe things together like in a shell).
• text formatting is parts of the fmt library standardized (https://github.com/fmtlib/fmt) and these things always require A LOT of work (seriously, it took GCC until version 11 to completely support "Elementary string conversions" from C++17 and Clang still hasn't complete support)

Not only that, Microsoft already completed C++20 nearly a year ago.

But well, this was mostly about the "I think Microsoft will eventually deprecate MSVC and fully embrace LLVM.".