News for hackers. Stuff that matters.
Re:The first new build of Circle, a new C++20 compiler, sinc... by tialaramex on Tuesday January 24, 2023 @07:58PM (#34512904)
Whilst that's clever I don't think it's actually practical at all.

I believe that your hypothetical approach, ignoring the fact it's not practical, is parametric polymorphism. We can invent more types of "needle" and use the same "needle" concept for other predicates, thus if we have N needles and M predicates that's N+M work, not N*M work as with the overloads.

However, what is actually practical, and thus what is done, is just ad hoc polymorphism via the overloading we looked at, if WG21 wants to expand it that's N*M implementation cost.

I do not believe we can claim something is ad hoc polymorphism solely because somewhere there's different implementation code for type A and type B as with your Godbolt example, if you believe that's ad hoc polymorphism surely you end up thinking std::sort is also ad hoc polymorphism which seems like nonsense.

Re:The first new build of Circle, a new C++20 compiler, sinc... by gpderetta on Tuesday January 24, 2023 @08:07PM (#34512970)
The begin/end overloads are ad-hoc polymorphism. The contains function is parametrically polymorphic.

My "hypothetical" approach is bog-standard generic programming in c++ has it has been practiced for almost 30 years since Stepanov originally codified it.

ADL was litterally designed to make this sort of stuff work.

Re:The first new build of Circle, a new C++20 compiler, sinc... by tialaramex on Wednesday January 25, 2023 @08:22AM (#34517933)
It's hypothetical because you yourself admit the standard library implementations don't actually do this here. The real C++ string contains() does in fact only work for the three specific types implemented, and is not generic, and that's not merely an oversight it's how it necessarily works even though it's worse. Circle's Interfaces would offer a much nicer approach, which makes sense because they do the same thing as Rust's traits for this scenario.

You're right that in some places C++ does the generic thing, I pointed at std::sort already - there are lots of examples of varying quality. The way we got here is that I pointed out overloads are the Wrong Thing™ and that's why it makes sense Carbon would want to outlaw them, and why no, outlawing them does not lose the nice property where the API feels generic - you can do parametric polymorphism and still have the generic API.

The main thing outlawing overloading gets rid of is actually functions/ methods which quietly have more than one distinct purpose. These functions are foot guns. Use your words, call the two (or more) things by different names reflecting the difference in intent and then fewer developers will mistakenly invoke the wrong meaning.

I don't like ADL either, but it's pretty far off topic.