3 ms·

> check that the type provided implements a comparison operator If I understand correctly, this is done with traits in Rust. In this case, the PartialOrd and O

> check that the type provided implements a comparison operator If I understand correctly, this is done with traits in Rust. In this case, the PartialOrd and Ord traits. More elaborate use cases for traits cover things like "is this type safe to send between threads" and "does this type have a statically known size on the stack".

avgcorrection 4y ago
Presumably they intended to say that the (1) cplusplus thing can express something that Rust cannot, and (2) here’s an example of Thing. But then they didn’t properly delineate the two things so that it might come off as if (2) is an argument for (1), but really (1) just talks about Thing in isolation and not as a comparison to Rust... The example was just a standalone example, unrelated to Rust.
- ncmncm 4y ago
  If you read what it says, you will see that it says Rust has built-in the most trivial of the things that concepts are used to do, and cannot express the rest at all.
  - tialaramex 4y ago
    Rust's traits actually reflect semantics, which is what you want, whereas C++ concepts are duck typing and you just get lots of wishful thinking when (too often) that's not enough. Take a look at Eq for example. Eq is a trait that inherits from PartialEq but has no actual syntactic requirements. It reflects equivalence. Choosing to implement Eq is a claim about equivalence for your type. It has semantics. With C++ concepts you'd have to invent a marker for that purpose, and so C++ does not have any equivalent to Eq. Instead it offers std::equality_comparable which models equivalence but only deliver syntactic matching on the != and == operators like Rust's PartialEq.
    - ncmncm 4y ago
      It is clear you do not understand the concepts feature in C++, so cannot meaningfully compare it to anything in Rust. It is no sin not to understand something, unless you go on to pontificate about it.
  - avgcorrection 4y ago
    I’m sorry man I can’t read.
tialaramex 4y ago
Nathan is talking about std::random_access_iterator which is a C++ 20 Concept, whereas the text in the blog said RandomAccessIterator which was a C++ 17 (and earlier) Iterator "category" now named LegacyRandomAccessIterator which doesn't actually do anything in code and so yeah you could just as well write T. C++ concepts are just duck typed, whereas Rust's traits have actual semantics. For example in C++ a float (the 32-bit floating point type) is std::totally_ordered because it has the necessary operators so "quack" - even though of course this type isn't actually totally ordered. If (when) you rely on this sort of promise your C++ program is "ill-formed, no diagnostic required"... In contrast Rust's 32-bit floating point type f32 is not Ord, because well, it isn't totally ordered is it? NaN. So sort() doesn't work on say a slice of f32, because sort is defined over totally ordered types. You will need to provide an ordering function to explain how you think they're ordered. C++ had no choice, you can't show up decades late to the party and say "Now we're defining these semantic traits" when there's so much code out there without them. Rust started from a fresh slate. Now, Nathan here (and many like him) would prefer to make a virtue of this necessity. Once upon a time (before Rust 1.0) Rust did actually have a trait named RandomAccessIterator but it was not well loved because it wasn't practical to do the optimisations you'd actually want (they'd be unsafe, and an unsafe trait here is a big pain point), yet without them it was too slow to be reasonable to suggest anybody use it. So it was abolished. In practice the slice type [T] is fine here, and the Ord constraint means this sort, like the real one defined on slice, enforces the requirement you'd actually expect. The Rust sort() implementation is safe here too, unlike the C++ one. It is also stable, because Rust chooses to give you a stable sort, and have people who know they need it write sort_unstable() when that's what they meant, whereas C++ assumes you'd better know exactly what you need or else too bad here's an unstable sort by default...
- ncmncm 4y ago
  The exact spelling of correct use of concepts differs from in the example code, but dwelling on it distracts from the valuable point. It is not correct to say that C++ concepts are duck-typed. They can be used in a sort of duck-typed way, if you choose to. But it is not the normal way to use them. And, using them only as far as Rust's built-in checking can go wastes most of their expressive power, which is unavailable to Rust coders.

avgcorrection 4y ago

Presumably they intended to say that the (1) cplusplus thing can express something that Rust cannot, and (2) here’s an example of Thing. But then they didn’t properly delineate the two things so that it might come off as if (2) is an argument for (1), but really (1) just talks about Thing in isolation and not as a comparison to Rust... The example was just a standalone example, unrelated to Rust.

ncmncm 4y ago
If you read what it says, you will see that it says Rust has built-in the most trivial of the things that concepts are used to do, and cannot express the rest at all.
- tialaramex 4y ago
  Rust's traits actually reflect semantics, which is what you want, whereas C++ concepts are duck typing and you just get lots of wishful thinking when (too often) that's not enough. Take a look at Eq for example. Eq is a trait that inherits from PartialEq but has no actual syntactic requirements. It reflects equivalence. Choosing to implement Eq is a claim about equivalence for your type. It has semantics. With C++ concepts you'd have to invent a marker for that purpose, and so C++ does not have any equivalent to Eq. Instead it offers std::equality_comparable which models equivalence but only deliver syntactic matching on the != and == operators like Rust's PartialEq.
  - ncmncm 4y ago
    It is clear you do not understand the concepts feature in C++, so cannot meaningfully compare it to anything in Rust. It is no sin not to understand something, unless you go on to pontificate about it.
- avgcorrection 4y ago
  I’m sorry man I can’t read.

tialaramex 4y ago

Nathan is talking about std::random_access_iterator which is a C++ 20 Concept, whereas the text in the blog said RandomAccessIterator which was a C++ 17 (and earlier) Iterator "category" now named LegacyRandomAccessIterator which doesn't actually do anything in code and so yeah you could just as well write T. C++ concepts are just duck typed, whereas Rust's traits have actual semantics. For example in C++ a float (the 32-bit floating point type) is std::totally_ordered because it has the necessary operators so "quack" - even though of course this type isn't actually totally ordered. If (when) you rely on this sort of promise your C++ program is "ill-formed, no diagnostic required"... In contrast Rust's 32-bit floating point type f32 is not Ord, because well, it isn't totally ordered is it? NaN. So sort() doesn't work on say a slice of f32, because sort is defined over totally ordered types. You will need to provide an ordering function to explain how you think they're ordered. C++ had no choice, you can't show up decades late to the party and say "Now we're defining these semantic traits" when there's so much code out there without them. Rust started from a fresh slate. Now, Nathan here (and many like him) would prefer to make a virtue of this necessity. Once upon a time (before Rust 1.0) Rust did actually have a trait named RandomAccessIterator but it was not well loved because it wasn't practical to do the optimisations you'd actually want (they'd be unsafe, and an unsafe trait here is a big pain point), yet without them it was too slow to be reasonable to suggest anybody use it. So it was abolished. In practice the slice type [T] is fine here, and the Ord constraint means this sort, like the real one defined on slice, enforces the requirement you'd actually expect. The Rust sort() implementation is safe here too, unlike the C++ one. It is also stable, because Rust chooses to give you a stable sort, and have people who know they need it write sort_unstable() when that's what they meant, whereas C++ assumes you'd better know exactly what you need or else too bad here's an unstable sort by default...

ncmncm 4y ago
The exact spelling of correct use of concepts differs from in the example code, but dwelling on it distracts from the valuable point. It is not correct to say that C++ concepts are duck-typed. They can be used in a sort of duck-typed way, if you choose to. But it is not the normal way to use them. And, using them only as far as Rust's built-in checking can go wastes most of their expressive power, which is unavailable to Rust coders.