Thanks for the feedback, that’s a fair concern. The original implementation brought quite a bit of format-specific machinery into the build system. The #embed suggestion has helped remove that complexity, although the question of where this functionality belongs is still worth discussing.
My main motivation is Embedded Swift and other environments without a filesystem. There’s also a related proposal showing interest in this area. While embedInCode might be relatively niche elsewhere, embedding assets directly into the executable is a frequent way of working in these file-system lacking environments. That’s where the cost of generating large Swift array literals becomes particularly relevant.
Does the simplified #embed approach address enough of the complexity concern to make this more reasonable as a built-in feature?
I’d also be glad to continue the plugin conversation; being able to iterate outside the toolchain is appealing. As we saw in the review of my other proposal, there are some build-integration challenges to work through, so I’d like to understand which ones this approach resolves and what would still be needed.