That will allow () unit to be used as closure that “swallows” it’s input, does nothing, and returns ().
Primary intention is to replace things like .map(|_|()) with more beautiful .map(()).
Implementing FnOnce<(T, T1, )> and further also might be useful.
The drop function can be used for this, e.g.
[1].iter().map(drop);
// ^~~~
Interesting; why not return the argument given back (i.e: the identity function).
That said, I don't think .map(()) is obvious wrt. meaning. I would be puzzled as to what this did if I saw it in the wild.
() doesn’t look like a function. Consequently it’d be IMO unintuitive if it implemented one of the Fn traits. If it did, it could sometimes even hide a bug.
If you see .map(|_| ()) in someone else’s code, it’s immediately obvious what it does, just from knowing closure syntax.
If you see .map(()) in someone else’s code, it’s not obvious what it does. (My first reaction would be, roughly, “Wait, what? () isn’t a function. There’s something really weird going on here.”)
Not worth it to save a few characters. This doesn’t make the code any more expressive, or readable, or maintainable, and there’s no functionality this would enable that you can’t do without it.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.