> I don't think that is untenable, performance wise, after all it is what everyone is currently doing in C++.
We have already made several decisions that will disadvantage us with regard to C++. When we have the opportunity to do better, performance-wise, than C++, we must seize it in order to maintain performance parity overall. On Sat, Jun 21, 2014 at 2:06 AM, Nick Cameron <li...@ncameron.org> wrote: > bstrie: you're right it is a trade off, but I don't agree that its not > worth it. We're talking about non-atomic incrementing of an integer - that > is pretty much the cheapest thing you can do on a processor (not free of > course, since caching, etc., but still very cheap). I've programmed a lot > in C++ with ref counted pointers and never had a problem remembering that > there is a cost, and it makes using them pleasant. I found all the clone()s > in Rust unpleasant, it really put me off using ref counting. The transition > from using references to using Rc was particularly awful. Given that this > is something C++ programmers coming to Rust will be used to using, I > believe ergonomics is especially important. > > 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. > > 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. > > 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. > > Cheers, Nick > > > On Sat, Jun 21, 2014 at 4:05 PM, Cameron Zwarich <zwar...@mozilla.com> > wrote: > >> 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 &. >> >> 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. >> >> Cameron >> >> On Jun 20, 2014, at 8:49 PM, Nick Cameron <li...@ncameron.org> wrote: >> >> 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. >> >> So, I guess +1 to spirit of the OP, but no solid proposal for how to do >> it. >> >> >> On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel < >> ben.strie...@gmail.com> wrote: >> >>> 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. >>> >>> >>> On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton <pcwal...@mozilla.com> >>> wrote: >>> >>>> On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:] >>>> >>>> Currently being Copy equates with being Pod. The more time passes and >>>>> the more code examples I see, it is amazing the amount of ugliness that >>>>> it causes. I wonder if there is a way out. >>>>> >>>> >>>> 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. >>>> >>>> Patrick >>>> >>>> _______________________________________________ >>>> Rust-dev mailing list >>>> Rust-dev@mozilla.org >>>> https://mail.mozilla.org/listinfo/rust-dev >>>> >>> >>> >>> _______________________________________________ >>> Rust-dev mailing list >>> Rust-dev@mozilla.org >>> https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >> >> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
