A few people responded to the criticism of D1040 on reddit, and clearly there are at least a few people who are keen to see
std::embed move forward. The rebuttals were imprecise, which obviously makes understanding the commenters’ concerns more difficult. However, the discussion did clarify a few things for me.
(This is not meant to be a counter rebuttal, but a lessons learned.)
The first thing is that there is a space where the current tools don’t work. There are two approaches to embedding binary assets: using
C as an intermediate representation, or trying to bypass the compiler. Examples of the first approach are tools such as
file2c. These tools don’t have any problems with portability, but they do run into a size limit. Examples of the second approach are tools such as
ld. These tools need to be aware of platform specific details to bypass the compiler, which I’d argue is acceptable as long as those details are well encapsulated, which they are. Unfortunately, they don’t work on Windows. In many cases, there is probably an acceptable tool, but if you need to support both large binary assets and windows, things become difficult. This doesn’t necessarily mean the compiler is the correct place for this functionality to exist, but it does show an unmet need.
The second thing is a need for dependency management. One commenter admitted to reimplementing the functionality of
xxd to support a project, and objected to the time it took to implement and debug his implementation. To be clear, each dependency has a cost, but preferring to maintain your own custom implementation instead of a depending on an existing solution is not healthy either. If it is too hard to access the ecosystem, there won’t be an ecosystem. This was part of the discussion around the proposal to add graphics to the standard library. I’m not suggesting go so far as leftpad, but the compiler and standard library shouldn’t need to bear the weight of the entire ecosystem.