Rust Traits vs C++ Concepts

Comments · 15

• BJ

  @bjugdbjk · 4 years ago

  U gys r crazy , Amazing rust content !! Thanks a ton.<br>Lately found this fabulous treasure in YouTube.

  1

• AR

  @arshsohi7221 · 4 years ago

  Exactly what I needed and was looking for! Thanks!!

• HA

  @haystackdmilith · 4 years ago

  Glad to see more people talking about Rust :)

  3

• JA

  @JamesBlacklock · 4 years ago

  So &quot;concepts&quot; seem kinda like Go interfaces: you automatically implement them if your type conforms to the spec. Interesting.

  1

• RE

  @redcrafterlppa303 · 4 years ago

  <a href="https://www.youtube.com/watch?v=f68FtmUTl3s&amp;t=1170">19:30</a> we need these anonymous interfaces in rust. It&apos;s annoying when you have shared behavior outside your crate and the author didn&apos;t define and implement traits. Maybe introduce a keyword that makes a trait bound loose and only looks if the trait could be implemented with an empty impl block.

• 3B

  @3bdo3id · 1 year ago

  <a href="https://www.youtube.com/watch?v=f68FtmUTl3s&amp;t=2819">46:59</a><br><br>How can I reach this repo to contribute?

• AL

  @alienm00sehunter · 4 years ago

  So concepts are kind of like Duck Typing?

• 9S

  @9SMTM6 · 4 years ago

  I think C++s concepts have, on a theoretical level, a few advantages and a few disadvantages compared to traits. But on a practical level they will sadly probably never be as powerful as Rusts traits.<br><br>There are a few things you didn&apos;t entirely follow up on, that empower Rusts traits over C++ concepts. <br><br>One of them is its interaction with virtual dispatch, which I would consider fairly brilliant. C++ has all these confusing rules about virtual functions and virtual Inheritance and the static variants (which can interact strangely). In Rust meanwhile you simply don&apos;t differentiate at definition (since you don&apos;t have Inheritance), and only the usage determines which variant gets used. Meanwhile elsewhere you get the performance of static dispatch (and the optimizations that allows).<br><br>In other areas they trade blows. For example, you can implement one of your Rust traits for any foreign type. Which you cannot for C++, with C++ you cannot add methods to classes, and you may not have access to everything inside to supplant the methods you would need (not to speak of the complication it would cause to have to handle multiple cases, certainly not helping with compiler errors). But, on the other hand, you what you cannot do with Rust is implement foreign traits for foreign types (ish, there are exceptions), because of coherence rules (in that situation also known as the orphan rules). That is trivial with C++, any type that conforms to the concept is accepted. But that also means false positives that may lead to weird behavior, eg. when a &quot;start&quot; method exists but doesn&apos;t do what you expected. Rusts traits are Nominal (though without Inheritance as a base for Polymorphism, but instead ad-hoc adoption with rules for coherence like the ones mentioned above), while C++s concepts are more akin to structural typing.<br><br>While we&apos;re on that topic, another thing that trait coherence kindof ruins (for now at least, there are efforts that would help) is that generic implementation of traits you mentioned (&quot;conditional method implementation&quot;). But first a bit of a foundation: As you said, Trait1 + Trait2 is an AND requirement. OR would not make sense in most casss if you think about it: All you know about the generic T is that it implements these trait bounds, and most of the time you would want to use the methods provided by these bounds, having then connected by OR means you can&apos;t use either of the methods. As you correctly stated, the way to do OR would be to have 2 seperate implementations. But now we get to the issue: What do you do if a type implements both Trait1 and Trait2? You have 2 different implementations. I&apos;m not certain right now where Rust will complain about that right now, but in any case it&apos;s not... Nice.<br><br>You would have to &quot;prefer&quot; one of these implementations above the other one. One way to archive that is with &quot;Negative Trait implementations&quot;, which you could add to the trait bounds, and exclude types that implement said traits. But they are not yet available to people without using nightly. They&apos;ve been that way for long, not sure why actually, gotta look up what&apos;s stopping them from being stabilized.<br><br><br>But yeah, in sum, it can be said that C++ concepts and Rust traits have advantages and disadvantages over each other. And C++ would not have been avow to adopt a system akin to Rusts traits retroactively anyways. But crucially, as you stated, C++ hasn&apos;t exactly been quick at adopting them anyways, with even many COMPILERS not supporting then yet, and as long as that&apos;s a thing there&apos;s going to be very little of the rest of the ecosystem using them, as you can&apos;t rely on them being present. Even of these issues would be solved at some point, given the past experiences with other features, most APIs still won&apos;t adopt being based on Concepts.

  2

• RI

  @rinket7779 · 2 years ago

  Anyone who claims C++ concepts are copying Rust traits has serious brain damage - concepts for C++ have been in development for more than 20 years, before Rust was even an idea.

  1