You must log in or # to comment.
But then you realise that the types of 10 constituent fields don’t implement Eq, PartialEq…
Now explain PartialEq, and why it’s mandatory.
NaN != NaN
I do appreciate how newer C++ standards have made these kinds of things a lot easier too.
Define all comparison operators with just one one line using C++20
auto operator<=>(const ClassName&) const = default;It’s nice that this exists these days, but my god is it horrendously unreadable at a glance
It makes it look like they’re just adding random noise to avoid colliding with existing syntax. Maybe they can try a UUID next time…
It makes perfect sense actually. I did write another comment here if you are interested.
This is how operator overloads were written going back to the initial version of C++ back in 1985. The only new thing is that we can now add
= defaultto get the compiler to generate a default implementation that compares all the member variables for you.
That is completely incomprehensible lol
Maybe to a non C++ dev, but a lot of C++ is probably incomprehensible to a non C++ dev, just like there are other laguages that are incomprehensible to C++ devs. To me it makes perfect sense as it works just like all the other operator overloads.
auto- let the compiler deduce return typeoperator<=>- override the spaceship operator (pretty sure it exists in python too)(const ClassName&)- compare this class, presumably defined in Class name, with a const reference of type Class name, i.e. its own type.const- comparison can be made for const objects= default;- Use the default implementation, which is comparing all the member variables.An alternate more explicit version, which is actually what people recommend:
auto operator<=>(const ClassName&, const ClassName&) = default;if I just want to have less than comparison for example I would:
This one makes it explicit that you’re comparing two Class name objects.
if I just want to have less than comparison for example I would:
auto operator<(const ClassName&, const ClassName&) = default;If I need to compare against another class I could define:
auto operator<(const ClassName&, const OtherClass&)
BuT ItS uNsAfE.
Only if you’re a bad programmer :/
This argument just doesn’t hold up. Software written by some of the best developers in the world still has these same bugs.
Why even use a language where you have to put so much effort into something that comes for free in many modern languages.
The problem with rust, I always find is that when you’re from the previous coding generation like myself. Where I grew up on 8 bit machines with basic and assembly language that you could actually use moving into OO languages… I find that with rust, I’m always trying to shove a round block in a square hole.
When I look at other projects done originally in rust, I think they’re using a different design paradigm.
Not to say, what I make doesn’t work and isn’t still fast and mostly efficient (mostly…). But one example is, because I’m used to working with references and shoving them in different storage. Everything ends up surrounded by Rc<xxx> or Rc<RefCell<xxx>> and accessed with blah.as_ptr().borrow().x etc.
Nothing wrong with that, but the code (to me at least) feels messy in comparison to say C# which is where I do most of my day job work these days. But since I see often that things are done very different in rust projects I see online, I feel like to really get on with the language I need a design paradigm shift somewhere.
I do still persist with rust because I think it’s way more portable than other languages. By that I mean it will make executable files for linux and windows with the same code that really only needs the standard libraries installed on the machine. So when I think of writing a project I want to work on multi platforms, I’m generally looking at rust first these days.
I just realised this is programmerhumor. Sorry, not a very funny comment. Unless you’re a rust developer and laughing at my plight of trying to make rust work for me.
Do you have some public code you could link to that you’re having this issue with? There isn’t a one-size-fits-all solution for Rc/RefCell, I think.
in which “other languages” is it so very hard?
In Python it’s really hard!
def __eq__(self, other): ...How do you even write those subscripted hyphens???
If you’ve got a complex and potentially nested object, what does the body of this simple function look like? That’s what they mean.
I mean, if your IDE does it for you, is it really that much better that it’s shorter?
not the IDE, its the compiler. this is also not some AI shit, in many cases (not all) the compiler can actually figure out how to do this, because it’s not hard, it would just be a lot of boilerplate if written manually.
Why did you even bring up AI? IDEs have been able to generate equality functions for decades without AI.
It’s kinda neat to have this defined directly in the language so that compilers can implement it, but creating equality function is so low effort that this doesn’t really seem like a big deal.
Like, you define the members in a class, then you tell your IDE to generate getters, constructor, equals, hashcode, etc all in like 5 seconds.
I like it, it’s nice when the language itself defines reasonable defaults for things, but realistically you’re saving yourself a few seconds of effort.Isn’t it obvious? More code to skim, scroll over and maintain if something changes. If you add a struct field, your manual EQ implementation still compiles and seems to work but is wrong and will lead to bugs. Yes, solving this for 99,999% of cases with an attribute is just far superior and does make a difference (while keeping it easy to manually implement it if needed). Hash and Ord and some other traits can be implemented in a similar fashion btw…
I said it was better, just not much better.
The maintenance costs of equals is nearly zero. Scrolling over boilerplate seems like a real stretch, like saying a novel with a picture every chapter is harder to read.
I like that you can’t accidentally forget to update it, which is kinda nice but is rarely a concern.
And it’s a bit more readable, which is nice.
It’s better, but folks are talking like it’s Super Jesus and I think it’s more like finding a dollar in the parking lot.Who said it was superjesus? It’s one of the smaller points on the long list of rusts advantages over other systems level PLs, but nonetheless notable. Especially if you consider that the feature that makes this possible is used for a ton of other useful stuff. And seriously, the boilerplate does matter, especially if you also add Ord, Hash and Debug impls. Your comparison with pictures in a noval makes no sense, since these add something valuable to the text and are easily distinguished from it. Heaps of boilerplate at a glance look just as meaningful as important sections of code, so being able to avoid it makes navigation significantly easier.
I know the image post was hyperbole, but the way y’all are gushing over it is borderline religious, in an unsettling way.
Immediately, you call boilerplate a Big Deal and identify yourself as a zealot. Even in Java, a notoriously verbose and boilerplate laden language, it’s a Small Deal unless you’re doing something insane. Let me guess, your coding in VI or something.
Rust looks great. It’s a bunch of small improvements over most languages. But True Believers of any lang need to chill the fuck out.
Implementing Equality in Haskell:
deriving (Eq, Ord)After learning how easy it was to implement functional programming in Rust (it’s almost like the language requires it sometimes), I decided to go back and learn the one I had heard about the most.
It opened my mind. Rust takes so many cues from Haskell, I don’t even know where to begin. Strong typing, immutable primitives, derived types, Sum types. Iterating and iterables, closures, and pattern matching are big in Haskell.
I’m not saying Rust uses these because Graydon Hoare wanted a more C-like Haskell, but it is clear it took a lot of elements from the functional paradigm, and the implementations the designers were familiar with had descended through Haskell at some point.
Also, deriving is not the same as implementing. One is letting the compiler make an educated guess about what you want to compare, the other is telling it specifically what you want to compare. You’re making, coincidentally, a bad comparison.
Don’t need the
Ordinstance for equality, justEqis sufficient.Ordis for inequalities.The point of the post is that most mainstream languages don’t provide a way to automatically derive point-wise equality by value, even though it’s pervasively used everywhere. They instead need IDEs to generate the boilerplate rather than the compiler handling it.
The first iteration of the Rust compiler was written in OCaml…
I’d argue that the reason this is so bad in other languages is because of horrible default implementations. Look at tostring in java, getting a somewhat printable object would be easy if the default implementation would use reflection or sth to print the object, but instead it prints hash gibberish no one cares about.
I always hated the implementation for
.toString()ofDuration. It gives you a string like that:PT8H6M12.345S(not a hash)Apparently, it’s an ISO 8601 thing, but what the hell am I supposed to do with that?
It’s not useful for outputting to end users (which is fair enough), but I don’t even want to write that into a log message.
I got so used to this just being garbage that I would automatically call.toMillis()and write “ms” after it.Well, and not to gush about Rust too much, but I recently learned that its debug string representation is actually really good. As in, it’s better than my Java workaround, because it’ll even do things like printing 1000ms as 1s.
And that’s just like, oh right, libraries can actually provide a better implementation than what I’ll slap down offhandedly.
Is that because it’s that simple, or just that the boilerplate is pre-written in the standard library (or whatever it’s called in rust)?
It’s because people put in the hard work of writing amazing macros instead of baking code reuse into the type system itself 😁 I’m a rust noob and I love the derive macro.
So it’s actually a secret third option! That’s pretty rad.
Derive macros are a godsend. There’s macros to automatically implement serialization as well. Basically a Trait that can automatically be implemented when derived
i’ve only read about rust, but is there a way to influence those automatic implementations?
equality for example could be that somethings literally point to the same thing in memory, or it could be that two structs have only values that are equal to each other
Not for the built-in Eq derive macro. But you can write your own derive macros that do allow you to take options, yeah.
Equality in rust is value equality per default, that’s what these traits are for. If you want to check pointer equality you’d use the
std::ptr::eqfunction to check if two pointers are equal, which is rather rare in practice. You can also implement thePartialEqtrait yourself if you need custom equality checks.
Yes, it is that simple. In Rust if you have a structure
Personand you want to allow testing equality between instances, you just add that bit of code before the struct definition as follows:#[derive(PartialEq, Eq)] struct Person { name: String, age: u32, }In Rust,
PartialEqandEqare traits, which are similar to interfaces in Java. Manually implementing thePartialEqtrait in this example would be writing code that returns something likea.name == b.name && a.age == b.age. This is pretty simple but with large data structures it can be a lot of boilerplate.There also exist other traits such as
Cloneto allow creating a copy of an instance,Debugfor getting a string representation of an object, andPartialOrdandOrdfor providing an ordering. Each of these traits can be automatically implemented for a struct by adding#[derive(PartialEq, Eq, Clone, Debug, PartialOrd, Ord)]before it.
Haskell:
deriving EqNewer Scala follows the same when enabling strict equaility. It’s a goos thing.
