That's the point of the challenge: "are there unknown properties of models allowing us to construct a poison for any network given enough input-output pairs".
The very point of CS as an academic discipline is _generalization_.
Linux the kernel is fundamentally inferior to NT from 30 years ago, Linux the userspace is barely tolerable, Linux as an ecosystem is an amateur clownshow barely held together by corporate donations of drivers and absolute dedication of a handful of volunteers of wildly differing skill.
If your biggest innovation of a decade is a carbon copy of a feature introduced in NT 3.5 in 1994 AND THEN it turns out most serious people disable it because you cannot even copy a feature without introducing new vulnerabilities - that's a sign of quality.
IDL/DDL is the source of truth, moving the type definitions there is the whole point. There is only one definition for each type, which is in the *DL, corresponding C++ headers are generated and everything is statically known.
Well, either you carefully vet which C++ features you use and my assumption still stands, or you don't - in which case I would rather not like to work in your company.
Reframe it as "you can do precisely what you need by generating code" and there is your answer.
Which is far better than to rely on a party which, as I said, has precisely nothing to do with what anyone needs. Which will inevitably produce solutions that can only partially (I am being generous here) be used in any particular situation.
As for "possibly buggy" - look, I can whip up a solid *DL parser complete with a C++ code generator in what, a week? And then polish it from that.
The committee will work for several years, settle on a barely working design, then it will take some years to land in major compilers, then it will turn out it is unusable because someone forgot a key API or it was unfeasible on VAX or something like that.
And my build process is not complicated, and never will be. It can always accomodate another step. Mainly because I don't use CMake.
It's the other way around. You are the real programmer and the committee and the "modern C++" crowd are more interested playing with legos instead of shipping actual software.
No way anything std::meta gets into serious production; too flexible in some ways, too inflexible in others, too much unpredictability, too high impact on compilation times - just like always with newer additions to the C++ standard. It takes one look at coding standards of real-world projects to see how irrelevant this stuff is.
And like always, the problem std::meta is purported to solve has been solved for years.
Sure, it took only what, 40 years of intensive hardware improvements* for assembly to move to the fringe? And we still reach out to it more often that I would like to because reasons?
Yep, I guess you can train an LLM on a bunch of binaries to get it to mimic a SotA compiler with some accuracy, which may or may not improve over time, but come on. Times where there were free performance increases are gone, and this is not the area where shipping any bullshit real fast will get you any sort of advantage.
* Which are unlikely to happen again in the foreseeable future.
Rust is - by design - antithetical to pretty much every idea of rapid application development paradigm Delphi/VCL and to lesser extent Qt adhere to.
It doesn't matter how many of Rust UI toolkits there are. Consider that there are a lot of Rust game engines, and pretty much zero games written in it, because even C++ gives you better trade-offs in that particular space.
The very point of CS as an academic discipline is _generalization_.