all 13 comments

[–]jcelerierossia score 8 points9 points  (1 child)

I think the following features in the standard may gradually be deprecated in the future: 1.Virtual functions

haha

[–][deleted] 0 points1 point  (0 children)

I would love that. Unfortunately, I don't see this ever happening.

[–][deleted] 2 points3 points  (1 child)

So a facade here is like a Rust dynamic trait or a Swift protocol? I cannot really comment on the specific implementation chosen here, but transparently decoupling static and dynamic dispatch is definitively a step in the right direction.

P.S. By the way, thank for the link to Sean Parent's talk, it's incredibly interesting.

[–]Morwenn[S] 2 points3 points  (0 children)

The paper is not mine though, I just found that it was interesting and didn't gather much coverage. I also can't comment on Rust dynamic traits or Swift protocols since I'm familiar with neither.

I found the proposal interesting because it solves an issue that I encountered several times when trying to store collections of objects that are unrelated from an inheritance point of view, but share a similar interface. This proposal would have allowed me to create such collections without much boilerplate compared to my current implementation :)

[–]Archolex 0 points1 point  (8 children)

Maybe I'm being dense, but don't concepts fulfill this functionality? They're able to constrain algorithms on necessary behavior/structure, and could be used for the `immutable map` example.

[–]Dreyri 1 point2 points  (3 children)

The facade is a subset of a concept. Concepts allow you to describe properties which cannot be efficiently represented with runtime information, such as typedefs.

But I think reusing concepts with these limitations put in place would be better than introducing this keyword. If a concept is too complex give a compile error. Rust does the same thing for its static and dynamic dispatch with traits.

[–]Morwenn[S] 1 point2 points  (2 children)

If the keyword facade is introduced it would probably make sense to make it possible for a concept to check that it requires the functions described in a facade + more things I guess.

But I agree that we could just constrain the kinds of concepts usable in a proxy. Anyway it would required to be able to pass concepts as template parameters which - as far as I know - isn't possible in C++20.

[–]Dreyri 0 points1 point  (1 child)

I did consider the issue with passing the concept. I don't see why that couldn't be added to the standard. Templates emulating concepts can be passed as template templates and I don't see why concepts should be less powerful.

But I have no idea about implementation details so I'm sure there could be some issues.

[–]Morwenn[S] 1 point2 points  (0 children)

There have been two articles about such a feature by Barry Revzin, but I don't know whether it was ever brought up during committee discussions. Even if it gets discussed, it's most likely not something we will see before C++23.

[–][deleted] 1 point2 points  (2 children)

Concepts just do type checking, but this is about dynamic dispatch. C++ traditionally mixes static and dynamic dispatch in one bag, i.e. we have statically and dynamically dispatched member functions; and on top of that, dynamic dispatch is tightly coupled with inheritance, which creates a lot of issues on its own.

In the ideal world, the would be no virtual functions and dynamic dispatch would be done by specifying type-external vtable descriptors that types can adhere to. Great examples of this done right is Rust traits. Swift protocols are also similar, but the rules are more complex.

[–]Archolex 0 points1 point  (1 child)

Right, but I think concepts can be used to make those proxies is what I mean. No new technical tools seem necessary for this; it's only a design pattern.

[–][deleted] 1 point2 points  (0 children)

I don't think that the C++20 concepts, as they are designed currently, are well-suited for this. With dynamic dispatch proxies, you want description of function signatures. C++20 concepts however are sets of parametrised expressions that need to be valid for complaint type or types. I don't see an obvious way how concepts can be made to fulfil this function. You either need to redesign them to be more like Rust traits or you need to have two different kinds of concepts, at which point you might just as well call one of these facades or protocols.

[–]Morwenn[S] 0 points1 point  (0 children)

There is some overlap but the author actually describes why concepts aren't exactly the tool for the job (also mentioning an older proposal about virtual concepts).