On Sunday, August 21st, 2022 at 10:39 AM, Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]> wrote:


>

> Well, as I understand it, Jason was interpreting your suggested "protocol" paradigm as a tweak to the existing C++20 Concepts paradigm (which it definitely can't be); it seems more likely to me that you intended it as Yet Another Paradigm in the multi-paradigm language that is C++. So if we allowed "protocols," then we'd have at least three competing/coexisting paradigms for polymorphic programming:
> - classical inheritance-based polymorphism
> - templates (i.e. unconstrained or constrained, but in either case not C++0x "concept maps")
> - "protocols" (i.e. Go interfaces, type erasure) <— this new thing


Yes. Swift has showed that a language
with C-style structs can have the first
the the third at the same time, Carbon
has showed that such a language with
all three above, is viable.


>

> Type erasure is based on unary interfaces by definition. It simply cannot handle STL-style webs of interrelationships between T, T::value_type, T::iterator, T::const_iterator, and so on. It doesn't work for that stuff. So "protocols" wouldn't be attempting to replace STL-style templates; "protocols" would just be yet another paradigm that programmers could choose to use or not.


I'm not familiar with the exact problem
you're referring to, although it sounds
like associated types, but there're
definitely things template-based
abstractions can do and protocols cannot.
Being said that, type erasure is a very
cheap utilization of parametric types.
It's cheap not because of its
implementations, which are often
more sophisticated than dyn traits in
Rust, but because it downsized its goal
a lot to be implemented, used, and
understood, as a library.


> (Now, I think having too many paradigms is a bad thing; but I recognize that that argument holds little water, because the "having too many paradigms" ship sailed in C++ sometime in the mid-1990s. ;))



Right. We care about numbers, but the
natural action should be ripping off
things that started as experiments and
people no longer use.


>

> It does occur to me that if all you want is "concept maps," you can get that today via basically the same mechanism that gave us std::string_view: write an adaptor that takes in a "suitably string-like" type and [...]
> (One problem is basically that
> protocol String {
> bool startswith(std::string s) const;
> }
> now forces `myString.startswith("hello")` to construct a `std::string` argument object, even when the original type would have known how to do the operation on a `const char*` more efficiently. Flattening overload sets in that way is usually not beneficial to performance. It has other advantages; but performance is not one of them.)


I know. It needs some innovation to
solve, maybe by offering alternative
signatures when the caller side is
known,


>

> and
> https://quuxplusone.github.io/blog/2021/02/13/blog-roundup/#i-also-learned-a-bit-about-auftr


and something like `if consteval` to
take a different code path when the
type is known.

--Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________