assuming you mean returning () (the empty tuple/void type) because it doesn't compose well with generics, macros, proc-macros etc. e.g. if you have this dump

assuming you mean returning () (the empty tuple/void type) because it doesn't compose well with generics, macros, proc-macros etc. e.g. if you have this dump way to wrap clone: `fn foo<T: Clone>(v: T) -> (T, T) { let new = v.clone(); (v, new) }` it would implicitly not work with T = (), because then `v.clone()` would be a "function which returns nothing". In isolation this might seem fine but if you compose abstractions you sooner or later run into an edge case where it isn't fine. And this becomes even more a problem when macros/proc-macros are involved. It also makes changing code easier, lets say you have something like `let x = foo(); dbg!(x);` and you change the return type it will keep compiling as long as the type implements `Debug`, even if you change the type to `()` (i.e. return nothing). And again for normal code that is a minor nit pick, but for macros, proc macros, generic code of sufficient complexity sooner or later you run into edge cases where it really matters that it's allowed. Not often but often enough. Lastly and most importantly assigning `()` to a variable hurts no one, you won't see any such code in normal PRs. So it it doesn't hurt anyone but can be quite use full in edge cases. Lastly linters (mainly clippy) do warn or error for some of this nonsensical things, depending on the lint-set you enabled.