Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well, that's partially true and partially false. Operators are syntax sugar for trait methods. Indeed, some operators can't be overloaded[1]. However, in that case, it's possible to make procedural macros that can handle such cases.

SQL builder programmers, for example, wanted assignment operator overload.

However, I'd argue that it's the wrong kind of overload to enable. The more code can do behind the scenes, the harder it is to reason about it, e.g. :

     c = b;
Is this an assignment? Will it start the DB connection? In Rust, it can be just one thing. By sticking that code in proc macro and translating code, you signal your intent that something funny is happening here and that you should consult docs for more info:

    sql!(a = b)
> It is easy to insist you have never needed any of that stuff for your library,

I didn't say it was easy. I didn't say it was impossible either https://mcyoung.xyz/2021/04/26/move-ctors/.

> Then there are the things the borrow checker will not let you do, that would be correct, but it can't see that.

Sure, but that's the Rice theorem at work (https://en.wikipedia.org/wiki/Rice%27s_theorem). Any non-trivial property of code is undecidable. That's why you have the unsafe escape hatch where you reason about why it's safe.

[1] which isn't that different C++ which prohibits some operator overload, but in C++ the list of operator not overloaded is small



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: