It’s essentially a less likely version of using the wrong callback, something which has undoubtedly happened in the fullness of time but is of no real concern.
No in my opinion the issue is the opposite: implicit structural interfaces make it harder to discover what interfaces a type implements, and what you can do with it.
A secondary effect being that mismatches have worse reporting, whether you’re trying to implement an interface or the interface has changed from under you the compiler only reports use site so from there you have to did out what the type is and why it does not conform anymore, things get worse if side casts are involved. There’s actually a pattern for checking conformance:
var _ Iface = (*Type)(nil)
Mmm yummy.Oh yeah and if the interface removed a method and you didn’t realise you might be dragging that useless methods for a long while. Then again it’s not like your Java-style interface is any different.
In C# I usually use explicit interface implementations. (They're inconvenient to type, but Rider has a macro for it.) When the interface changes or disappears, my code won't compile.
There's code that can be allowed to fail, and furthermore, it will eventually fail due to the sheer amount of this code, the development time constraints, the number of possible game states, etc. I don't care that this code rarely fails under some arcane conditions, because this simply causes some button to stop working, some NPC to stop moving, but the game will remain playable. Even if the player notices the bug, they'll just shrug and keep playing. My aim is to make sure that the game recovers and returns to a healthy state after the level/save is reloaded. (Obviously, I'd like to fix/avoid every single possible bug, but it's impossible in practice. You'll have more luck continuously tracking in your head how dangerous the code you're working on is. Also, you rarely have the luxury of being the only programmer on the team. Bugs will happen.)
The other kind of code is the core game system stuff, the low level stuff, the error handling stuff, the memory stuff, the pointer stuff. You must pay special attention while working on this code, because failures will straight up crash the process or bring the game into an irrecoverably broken state (eg. all objects stop updating, stuck in some menu, the player never respawns...). Bugs like these are also highly prioritized by management. My update loop needs to be shiny.
Such is the reality of working on complex systems (or simple object-oriented programs ;))
(Note that bfloat16 has a different range than float16, so you can't interpret one as the other)
By the way, I have no idea what your point is.
Deleted Comment
Worth it, though. It's one hell of a laptop.