The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Let's use an example then. Is it really up to debate/belief, that a static_cast<T> is better, than it's counterpart, the classic cast? The cast where the compiler can check if the cast makes sense and tell me if it doesn't really isn't better than a simple "Shut up and shove the memory", is it? Of course a static_cast isn't always applicable, but then there's dynamic_cast<T> and the rest of the family and while one of the members ain't any better than the cast of olden, it doesn't have to be used in every case where you need a cast. With the old system, there's only one option, the rather dangerous one. Another example, MMA. Manual memory allocation. I simply don't believe you that there's advantages to it when a smart pointer or a library container does the job as well. Well, when talking to a memory-mapped device, static memory is all there is, laying a library container on top will only screw things up because I don't control the memory layout anymore. But that's an edge case, when it comes to business logic, letting the compiler/library do the job is in far most cases superior. Yet the oldtimers insist on doing things the old way no matter whether it's a better idea or not.
The issue I am talking about is that Oldtimers don't bother distinguish between cases, they go with old-and-tried (and difficult to use and dangerous) for the sake of it, not because it's a better idea. And really, unless you write low-level-code (which, let me just put that as a claim, Python programmers usually don't do), the new ways of more abstraction are superior.
But so much allocate of memory is within a class already. There's nothing really gained by wrapping those things in a smart pointer. It's just more moving parts and syntax and generated code. The memory is already owned and managed by the object that allocated it, and of course deleting those things in the destructor allows you to catch any errors and log them for in the field diagnosis, which you can't do if you are just letting a destructing member delete the memory.
If you are passing allocated objects around, then of course it makes a lot more sense, but that's nothing new. It's been going on for a long time and isn't modern per se.
I certainly agree that stuff like override, member delete, member default, static_cast and such are significant improvements and they don't bring lots of baggage with them that you don't want, unlike a lot of other new stuff. Things like that, which improve type safety and the ability to express semantics are always a good thing in my opinion. I can't believe that we still don't have the option for explicit parameter direction indication.
But that's the problem, you didn't say explicitly what it should be. If the right side gets accidentally changed, nothing is going to complain if what it got changed to supports the same interface (not terribly uncommon in the modern world if lots and lots of operator driven stuff.)
If you explicitly say what it's supposed to be, then two things have to get simultaneous broken in the same way. If you don't, then only one has to get broken for potential silent errors.
If that was the case I wouldn't use auto . The situation you described is actually a feature of the auto keyword. It's pretty useful to only change the initializer without have to change the type declaration during refactoring.
I don't think the point of a language should to make it easy to refactor without having to really think about what you are doing and the potential silent errors it could introduce. Significant refactoring isn't common and it should be approached very carefully. Being explicit it always safer.
I remember trying to install Mathematica, which uses some library that is distributed with VC++, and there had been so many installs over the years that it just wouldn't work. I had to do a whole OS system wipe to get it to work.
I think they just hop to it, buck up and get the job done.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle