Rust's where Clause: The One Trick That Saves Your Function Signatures

[00:00:00]If you have ever written a generic function in Rust and your function signature started looking something like this and you felt your eyes glaze over trying to read it. Well, there is a cleaner way. Today we are talking about Russ clause. What it does, when to use it, and the handful of cases where it's not just nicer for reading purposes, it's only way to write what you need.

[00:00:25]So, let's discuss. Generic bounds in ROS normally live right next to the type parameter, something like this. Now, that's fine for one bound on one type, but real production application code often has multiple type parameters, each with multiple bounds. Look at this.

[00:00:44]Three type parameters, each with its own list of bounds wrapped inside the pair of brackets looks terrible. And even before you could reach your parameters, you are hit by this wall of text. And even if this code is wipe coded, you still want to understand the signature of what's going on. What is this function supposed to do? And when you see this, I mean, it's very difficult to read. And yes, you can do all of that formatting and stuff, but things only get worse. Think about the case when we already have three parame parameters and it's already too much. But what if I add another one and then that's also a type parameter. Things just get from back to worse and it lacks vis readability. It lacks u kind of visibility as well in terms of you always have to move left to right to know what's really going on. So this can't be the only way or only correct way to write this approach or work with this.

[00:01:45]And that's where we use the wear clause as it lets you move the bounds out of this terrible looking angle bracket and put it after the return type. Same function, same meaning, much easier to scan. Nothing changed functionality wise. The compiler treats all of these versions same or identical. What changed is readability. Each bound gets its own line. So it's much easier to read and understand what exactly is the parameter or what is the expected parameter type and you can actually see the functions shape before hitting a wall of you know terrible looking text that we have right here. Everything we have seen so far is a use case of beer clause to improve the readability. What looked like this, a terrible wall of text is now boiled down to look something like this, which is way easier on ice because you could just read it that T must implement both clone and debug. And similarly, U must be an iterator that yields item of type D and U itself must also implement the clone.

[00:02:54]So much easier on ice, easier readability wise. But as I mentioned in the start, wear clause doesn't just end here. We also have cases where it's must. Look at this one. Here is where it gets interesting. There are cases literally you can't express with inline bounds. Look at these bounds for example. Now the second one is straightforward. T must implement display. Straightforward. But look at this one. You are constraining vector D itself. Not just the T but the vector T.

[00:03:27]There is no slot for this in the angle bracket. Let's try it even. So let's say we have T must have clone and whatever.

[00:03:33]But let's wrap it. Instead we do vector T and we get an error. Basically this is not even allowed or let's say even if I copy this as it is and I put this right here. Boom. So this is not even allowed in in N9. And that's when you have to use the wear clause. And look at this right here. You are bounding for associated types.

[00:03:59]So you want to say something about I item the item of the iterator not the I.

[00:04:06]Now inline syntax can't reach into associated types. That's why you have to do the wear clause. Similarly you have got bounds involving closure function traits or several layers of generics.

[00:04:19]That's when wear clause keeps the signature from turning into that unreadable single line jargon like this.

[00:04:27]So the rule of thumb is one type one simple bound in line is fine. Anything more than that just go for wear clause because you see the wear clause is not just for aesthetics and something which is nice to have or cool to have and makes your code look pro uh or you can ignore it whenever you want. That's not the case. They are how you keep your complex generic code readable and maintainable. And for associated types, non-parameter bounds, they are the only tool that you have. That's how you transform your complex or you know unreadable code from here to here. And then for some specific cases, um you basically need it as we just discussed.

[00:05:09]If this helped, drop a like and let me know in the comments what's the messiest generic signature you have had to untangle. I'll catch you guys with another interesting topic. Bye-bye.