LÖVE

I might be mistaken but if I read it right, your entire problem with this is that you created something with a critical bug in it yet it somehow worked on your machine, but on others' machines it failed, and you want the LOVE framework to fail silently on such a critical bug, because on your machine it was somehow working and you wanted it to be that way for everyone - with no extra effort from you.

"Works on my machine" is not meant to be taken unironically. In fact, the reason why it exists is to mock people who don't test things on any other setup than their own machine.

If there's one thing I can take away from all of my programming experience, is that nothing substitutes actual testing. NOTHING. Ever.

You didn't read it right. My (hypothetical) code does not have a critical bug in it; I didn't do anything wrong. Having an unused variable is not, or should not ever be regarded as, a critical bug; it's a valid programming pattern. For example, Lua doesn't punish you with errors if you have unused variables in your code (not even if you misspell a variable; only if you use the resulting nil value in a context where it doesn't make sense). C compilers typically emit warnings, NOT errors, in case of unused identifiers, and you can disable these warnings.

The "actual testing" you're suggesting is unrealistic. Even if I tested it in every OpenGL implementation out there (impractical), some future driver could be smarter about optimization and remove more variables, and then my thoroughly well-tested code would crash in that driver. Who would be to blame?

- The programmer, for following a coding pattern that makes possible future changes more comfortable?
- Every driver the programmer tested the code in, for not being clever enough to optimize out some variables?
- The driver that applies more aggressive optimizations, for optimizing out things that can potentially make the shader faster?
- The engine, for erring on something against the recommendations of the OpenGL creators?

I'd go for the last. Remember, again, that the OpenGL wiki recommends to just ignore the situation and keep going. It does not recommend throwing an exception and forcing the user to remove the unused variable.

All I'm asking is that LÖVE sticks to that recommendation, just returning a value for diagnostics. It keeps adding to the amount of stuff I have to monkey-patch in LÖVE.

Corrected function which returns the diagnostics:

The "recommendation" doesn't recommends anything, it merely explains why your uniforms defined in shader code might not exist in actual GPU program. Then it mentions that glGetUniformLocation returns -1 if it doesn't exist and glUniform will quietly eat it. This was Kronos' choice, because apparently developers cannot be trusted to produce semi-valid GLSL code, nor be bothered to safeguard against it ("nearly every game ships broken"). LOVE's choice is to throw an error because knowing something's wrong with your code is more important than having it try its best at continuing to run in spite of bugs and errors. Video games ain't web pages - if it crashes, it crashes, and you go and fix it.

In the future your game will stop working altogether and will require an emulator to run at all. It's silly to position an argument like this. You are however expected to test your program on all of its target hardware and software configurations, which may be something from the past or something that currently exists, either way you're fully responsible for making sure it runs for everyone who would be running it; the uniform behavior difference is just the tip of the iceberg. That's just how it is. "Works on my machine" isn't an excuse.

If you wanted to have the same behavior as OpenGL, you should patch the /modules/graphics/opengl/Shader.cpp file to return a blank Uniforminfo with "-1" for an address instead of returning nullptr, in case it doesn't exist. Then again, LOVE doesn't only runs on OpenGL (it currently does but that'll change soon) and behavior like this is not necessarily the standard.