Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If they do, there's no harm done. The new this inference stuff is just a brevity enhancement, yes?

You have to understand that it's a Sisyphean struggle to get people to use modern C++ features at all. You still see people passing around std::string instances by value and manually calling new and delete. They're ignorant of variants and think "final" is an advanced feature. I'm happy if they get as far as understanding even how to use CRTP.

There's a vast gulf in skill between the expert C++ practitioner who appreciates a blog post like the one linked and one who's been dragooned without training into writing some enterprise C++ thing. The latter relates to C++ as an inscrutable Lovecraftian god who might eat him slightly later if he makes the right cultist noises and does the right syntax dance.



There is yet another thing with deducing this: no more pointer-to-members:

``` class A { int f(this A & self, float b); }; ```

Type of &A::f is int ()(A &, float), not int (A::)(float).

This is huge for template metaprogramming function deduction if you stick to it because that generated a lot of template instantiations to cover all cases.


But then you'll break if someone supplies a "real" member function. Is this even a big deal with std::invoke, which lets us treat regular functions and PMFs uniformly?


std::invoke I am guessing it could somewhat instantiate quite a bit of code? Not sure thoug. But it is a template signature. And it is not the only problem with pointers to members. When doing signature introspection you need a ton of combinatoric template specializations. Getting rid of a family of instantiations by sticking to deducing this seems like an attractive approach.


I wouldn't call it harmless. The feature might just be brevity enhancement for CRTP (and I think it's incredibly well-designed for that), but the advertisement/education around it usually just mentions constness-agnosticism and code deduplication as the use cases, which are precisely the wrong cases for deducing this. CRTP was never the solution for those and that hasn't changed with the syntax -- because both of these have effects on code semantics, not just syntax. But I will bet most people using it will use it for those purposes, rather than as a briefer syntax for when they would've otherwise used CRTP.

It feels a lot like the push_back -> emplace_back thing, where the feature has important use cases, but plenty of people will use it merely because they're mistaught that it's the "modern way" to do things without being told it's a footgun that bypasses existing safety features in the language, and it becomes impossible to hold back the flood. And they get away with it the majority of the time, but every now and then they end up introducing subtle bugs that are painful to debug.

But hey it's the shiny modern hammer, so obviously you can't just let it sit there. People can't just see a modern hammer and let you watch it sit there until you actually need it. You have to use it (and people will tell you to use it during code reviews) or everyone will look down on you for being so old-fashioned and anti-"progress".


It can also pass this by value, which is good for optimization. And it gets read of pointer-to-member functions, which is great.


Probably thats also partly because they are being dumped into a large sprawling codebase already full of C++98 idioms. Even if you point them to the "newer sections" that are more modern, they will fall back to what they are working with all the time.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: