Stream: t-libs/wg-allocators

Topic: `Copy` trait in combination with custom allocators?


Erich Gubler (Oct 16 2019 at 18:37, on Zulip):

IIUC, Copy's semantics are that Clone::clone can be automagically called to produce owned values when they would normally be consumed. I can't see why a sane person would mark something that would require a custom allocator as Copy, but has the interaction been discussed yet?

Erich Gubler (Oct 16 2019 at 18:39, on Zulip):

EDIT: fixed botched initial content. :P

Tim Diekmann (Oct 16 2019 at 18:48, on Zulip):

I don't see why this should be a problem. Could you elaborate, where this will be an issue?

Erich Gubler (Oct 16 2019 at 18:56, on Zulip):

I don't see a problem, per se. I just realized that it might be surprising to have implicit usage of a given allocator. For instance, if one used Copy for elements using a bump allocator it might exhaust resources faster than expected.

Erich Gubler (Oct 16 2019 at 18:58, on Zulip):

I honestly don't think anyone should be combining the two would be a good idea in the first place, but I was also surprised to discover the suggestion in std docs:

When *should* my type be Copy?

Generally speaking, if your type can implement Copy, it should. Keep in mind, though, that implementing Copy is part of the public API of your type. If the type might become non-Copy in the future, it could be prudent to omit the Copy implementation now, to avoid a breaking API change.

Erich Gubler (Oct 16 2019 at 19:00, on Zulip):

I think most people are of the opinion that they shouldn't use Copy for data structures that allocate. This is just some mildly interesting paranoia on my part, I think.

Tim Diekmann (Oct 16 2019 at 19:03, on Zulip):

I think most people know that they shouldn't Copy things that allocate.

I share your thoughts. I think we don't have to care about that use case.

Erich Gubler (Oct 16 2019 at 19:05, on Zulip):

As for what the interaction would be, let me just check my understanding. If a type is Copy, then generally it would be expected to use the same allocator under the hood since the approach for parameterizing allocators locally will always be via type, right?

Tim Diekmann (Oct 16 2019 at 19:06, on Zulip):

I think unless we are introduce a trait CloneIn this would also hold for any clonable object.

Erich Gubler (Oct 16 2019 at 19:08, on Zulip):

Okay. I think that this conversation can be closed, then. :) I'm considering recording it in Github as a (closed) issue, but I don't know if anybody cares. Thoughts?

Tim Diekmann (Oct 16 2019 at 19:09, on Zulip):

I don't think an issue on GitHub is needed here :)

pnkfelix (Oct 28 2019 at 13:59, on Zulip):

IIUC, Copy's semantics are that Clone::clone can be automagically called to produce owned values when they would normally be consumed.

I just wanted to point out here that part of the idea behind Copy is that we do not let you use a custom Clone implementation for such types. All that cloning can do for such types is memcpy their immediate state into the destination place. I do not think it is possible for there to be any interesting interactions here with custom allocators, by design. However, I welcome a counter-example.

Last update: Nov 15 2019 at 09:40UTC