I know this has been discussed a bit, and that many users like it to be clear when a reference (especially a mutable one) to an object is passed to a function. But when the object supports Copy semantics?
See this example: a thin wrapper around a number which is used as a hash-map key and a function value. I don’t see the utility of requiring &x to be explicitly referenced. If need be, the compiler can always create a copy and pass a reference to that.
I also don’t see why the explicit dereference (take(*map...)) is required. Dereferencing is already automatic when calling a function on a referenced object, and it’s unambiguous (whether the object is Copy or not).
I’m just slightly peeved because I’ve seen hundreds of these errors (expected Num, found &Num, or vice-versa) by now, and usually don’t find it worth the bother of working out whether the object in question is already a reference.