tw061023

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.

Sometimes having a good kernel matters more than having a good userspace.

That's... definitely a way to describe Sean Barrett, whose excellent libraries popularized this style.

Zero accountability. Which proves yet again that accountability is the final frontier.

That, uh, says a lot about Google, doesn't it?

Take a look at Github accounts of people pushing it, and you will see a clear pattern - it works, apparently, for a _very_ specific subset of people.

[flagged]

Why would I want to write a C++ parser?

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.

If you would check my comments, you would see I am quite aware. And no, it will not, just like it was with streams, ranges and whatever else.

Which problem would this solve for them?

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.

Which use cases? What exactly you can do with "existing metaprogramming facilities"?

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.