<div dir="ltr"><div>I am assuming that people will use Rc not out of choice, but when they have to. We can trust our users to use ownership and references where possible, after all these are the easiest things to use, and privileged in all the Rust docs and tutorials. We will still need style guides in Rust and we will still tell people to prefer ownership to ref counting. We should assume our users are smart, if they don't understand the trade-offs around ref counting, then they are going to have much bigger problems writing systems code than a few extra counter increments.<br>
<br></div>Ownership does not always work, graphs often appear in programming. When they do, you have to use Rc or Gc to cope. We shouldn't punish programmers who have these problems to deal with. Telling them to use ownership is pointless if your data is not hierarchical. In this situation, we are not encouraging users to use ownership instead of ref counting, we are encouraging them to use garbage collection, even when that is not the optimal solution for their problem.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 10:29 PM, Val Markovic <span dir="ltr"><<a href="mailto:val@markovic.io" target="_blank">val@markovic.io</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Fri, Jun 20, 2014 at 11:06 PM, Nick Cameron <span dir="ltr"><<a href="mailto:lists@ncameron.org" target="_blank">lists@ncameron.org</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>I found all the clone()s in Rust unpleasant, it really put me off using ref counting.</div>



</div></div></div></div></blockquote><div><br></div></div><div>I consider that to be a feature, not a bug.</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div dir="ltr"><div><div><div><div>Given that this is something C++ programmers coming to Rust will be used to using, I believe ergonomics is especially important.<br></div></div></div></div></div></blockquote><div><br></div>



</div><div>I write C++ for a living in a massive codebase and shared_ptrs are used extremely rarely, and it's <i>not </i>because of the perf overhead of the atomic increment/decrement, but because using shared_ptrs obscures ownership. People tend to just put some memory in a shared_ptr and not care which part of the system owns what and that ends up producing code that's very hard to reason about and maintain.</div>



<div><br></div><div>unique_ptrs have made the transfer of ownership of heap-allocated memory super-easy. Damn-nigh every design can be expressed with unique_ptrs owned by the logical owners of that memory passing refs or const refs to other parts of the system.</div>



<div><br></div><div>So please don't represent that shared_ptrs are commonly used in all good C++ code. Experience has thought me and others to look at shared_ptrs as a code smell and something to be flagged for extra clarification by the author in code review. I hate to quote the Google C++ style guide since it has many flaws, but this is <a href="http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Ownership_and_Smart_Pointers#Ownership_and_Smart_Pointers" target="_blank">one of the things it gets completely right</a>: "<span style="color:rgb(51,51,51);font-family:sans-serif;font-size:13px">Do not design your code to use shared ownership without a very good reason.</span>"</div>



<div><br></div><div>Rust has unique_ptrs in the form of ~ and they're doing their job just fine. Rust needs special support for Rc ergonomics as much as it needs such support for Gc, which is none at all. In fact, making Rc and Gc pointers more difficult to use should steer people away from such poor design crutches.</div>
<div><div class="h5">

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div>
<br></div>In this case I don't think we need to aim to be more 'bare metal' than C++. Transparent, ref counted pointers in C++ are popular and seem to work pretty well, although obviously not perfectly.<br><br>




</div>zwarich: I haven't thought this through to a great extent, and I don't think here is the right place to plan the API. But, you ought to still have control over whether an Rc pointer is copied or referenced. If you have an Rc<T> object and pass it to a function which takes an Rc<T>, it is copied, if it takes a &Rc<T> or a &T then it references (in the latter case with an autoderef-ref). If the function is parametric over U and takes a &U, then we instantiate U with either Rc<T> or T (in either case it would be passed by ref without an increment, deciding which is not changed by having a copy constructor). If the function takes a U literal, then U must be instantiated with Rc<T>. So, you still get to control whether you reference with an increment or not.<br>




<br></div>I think if Rc is copy, then it is always copied. I would not expect it to ever move. I don't think that is untenable, performance wise, after all it is what everyone is currently doing in C++. I agree the second option seems unpredictable and thus less pleasant.<br>




<br></div>Cheers, Nick<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 4:05 PM, Cameron Zwarich <span dir="ltr"><<a href="mailto:zwarich@mozilla.com" target="_blank">zwarich@mozilla.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I sort of like being forced to use .clone() to clone a ref-counted value, since it makes the memory accesses and increment more explicit and forces you to think which functions actually need to take an Rc and which functions can simply take an &.</div>




<div><br></div><div>Also, if Rc becomes implicitly copyable, then would it be copied rather than moved on every use, or would you move it on the last use? The former seems untenable for performance reasons, since removing unnecessary ref-count operations is important for performance. The latter seems unpredictable, since adding a second use of a value in a function would mean that new code is implicitly executed wherever the first use is.</div>




<span><font color="#888888"><div><br></div><div>Cameron</div></font></span><div><div> <br><div><div>On Jun 20, 2014, at 8:49 PM, Nick Cameron <<a href="mailto:lists@ncameron.org" target="_blank">lists@ncameron.org</a>> wrote:</div>




<br><blockquote type="cite"><div dir="ltr"><div>I think having copy constructors is the only way to get rid of `.clone()` all over the place when using` Rc`. That, to me, seems very important (in making smart pointers first class citizens of Rust, without this, I would rather go back to having @-pointers). The trouble is, I see incrementing a ref count as the upper bound on the work that should be done in a copy constructor and I see no way to enforce that.<br>





<br></div>So, I guess +1 to spirit of the OP, but no solid proposal for how to do it.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel <span dir="ltr"><<a href="mailto:ben.striegel@gmail.com" target="_blank">ben.striegel@gmail.com</a>></span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I'm not a fan of the idea of blessing certain types with a compiler-defined whitelist. And if the choice is then between ugly code and copy constructors, I'll take ugly code over surprising code.<br>







</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton <span dir="ltr"><<a href="mailto:pcwalton@mozilla.com" target="_blank">pcwalton@mozilla.com</a>></span> wrote:<br>







<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]<div><br>




<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Currently being Copy equates with being Pod. The more time passes and<br>
the more code examples I see, it is amazing the amount of ugliness that<br>
it causes. I wonder if there is a way out.<br>
</blockquote>
<br></div>
Part of the problem is that a lot of library code assumes that Copy types can be copied by just moving bytes around. Having copy constructors would mean that this simplifying assumption would have to change. It's doable, I suppose, but having copy constructors would have a significant downside.<br>








<br>
Patrick<br>
<br>
______________________________<u></u>_________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/<u></u>listinfo/rust-dev</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>Rust-dev mailing list<br><a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>




</blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Rust-dev mailing list<br>
<a href="mailto:Rust-dev@mozilla.org" target="_blank">Rust-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/rust-dev" target="_blank">https://mail.mozilla.org/listinfo/rust-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>