Why are `&` and `mut` annotations required at the invocation (i.e. use site) of a function instead of implicit conversion?

[shelby3]

@mbrubeck

If the type has destructors, then it can matter greatly. For example if I create a CString and then pass cstring.as_ptr() to some C code, then I need to know that the destructor doesn't run while the C code can still access that raw pointer.

So the issue is unsafe code.

<subjective>So we litter all our safe code for the unsafe case.</subjective>

I think I will bow out of the discussion, because I think I would first need to be convinced of the value of this very complex low-level structuring of resource lifetimes, before I would invest the effort to think about how I might design it to have fewer of what I perceive IN MY OPINION to be warts and corner cases. At this time, I am thinking GC is what I want for 80-95% of my code and the other 5-20% is going to need to be very carefully coded in any case.

@lambda

When looking at that change, it makes it very clear that I am now passing ownership to bar, and thus consuming a. I might object in code review "no, we shouldn't be calling bar since we are about to do another change that will require more functions that process a, we should call bar_ref instead." Without that extra annotation, there wouldn't be a way to tell that foo and bar were taking the value in a different way, which would make this change a lot easier to miss.

Actually I had started to think about how I would have designed it differently, because for example & at the call site to me means "take the address of" so it appears to mean pass a pointer to the function, thus it appears to mean "move" and not "borrow". The & the function declaration site should be an * to be more consistent with C/C++ lineage so as to avoid confusion due to ingrained habit.

My most significant thought was that perhaps move should be the annotated case! Because moving should be rarer. I suspect that would clean up most of the noise, but I didn't think through yet all the issues with the change.

---

I didn't intend to offer my opinion on this. That is why I had hinted to @arielb1 that I felt the decision was already made and I wasn't interested in pushing it.

Given @arielb1 wanted to discuss it further, I have since explained some of my thoughts and strong doubts. That is sufficient I think so the viewpoints are out there. This low-level resource lifetime feature really isn't a priority of mine at this time. So I am wasting time here if I discuss further. Hopefully you can take my viewpoints into account FWIW. Thanks.

No harm is intended to Rust nor anyone here. I sincerely just want to work out what are the best tools or how tools fit various use cases. No ill will intended. I knew I didn't want to discuss this because I knew it was a topic that would become inflamed very quickly.