Where database blog posts get flame-broiled to perfection
Alright, settle down, kids, let The Relic here translate this latest dispatch from the land of artisanal, handcrafted code. I've read through this little "journey," and it smells like every other magic bean solution I've seen pitched since we were still worried about the Y2K bug corrupting our tape backups. You think you're clever, but all you've done is reinvent problems we solved thirty years ago.
Let's break down this masterpiece of modern engineering.
First off, your entire premise is that your programming language is so brilliantly complex it can't tell the difference between a function call and a less-than sign. Congratulations. Back in my day, we wrote COBOL on punch cards. If you misplaced a single period, the whole batch failed. We didn't call it "ambiguity"; we called it a mistake, fixed it, and re-ran the job. You've built a skyscraper on a foundation of quicksand and now you're selling tickets to watch it wobble. This isn't a feature to explore; it's a design flaw you've learned to call a personality quirk.
Your "absolutely crazy workaround" is the digital equivalent of building a Rube Goldberg machine to butter a piece of toast. You're overloading operators and metaprogramming a monstrosity just to avoid typing ten characters the compiler explicitly told you to type. We had a name for this kind of thing in the 80s: job security for consultants. You're not hacking the system; you're just writing unmaintainable code so you can feel clever. It’s like refusing to use a C-clamp because you want to prove you can hold two pieces of wood together with a complex system of levers, pulleys, and your own hubris.
And the cost of this "solution." Good heavens. You proudly state that your little trick will "sacrifice all your RAM" and "eventually the OOM killer" steps in. You killed the compiler process on a machine with 300 GIGABYTES OF RAM. I used to be responsible for a mainframe that ran an entire international bank's transaction system on 32 megabytes. We treated every byte of memory like it was gold, because it was. We'd spend a week optimizing a query to save a few kilobytes. You kids treat system resources like they're an infinite-refill soda fountain.
On my machine, this quickly leads to furious swapping of memory and eventually the OOM killer killing the compiler process... Don’t try this at home!
Don't try this at home? Son, you shouldn't try this at work, either. This is the kind of code that gets written, checked in on a Friday, and then pages me on a Sunday while I'm trying to watch the game because the production build server has melted into a pile of slag.
The grand finale of this whole saga is that you rediscovered fire. After your "journey into C++ template hell," your stunning conclusion is that the template keyword is, in fact, necessary to disambiguate the code. This is like setting your house on fire to appreciate the fire department. You didn't make a discovery; you just took the most expensive, time-consuming, and resource-intensive path back to the exact starting point the compiler documentation laid out for you. This whole exercise is a solution in search of a problem, and the only thing it produced was a blog post.
You didn't innovate. You wrote a long, complicated bug report and called it an adventure. We were doing dependent types in DB2 stored procedures back in '85, and guess what? The parser didn't get confused.
Now if you'll excuse me, I've got a backup tape that needs rotating, which is somehow still a more productive use of my time.