Expect to add a smart pointer with only strong references count

libs
1

In some cases, weak reference counting is not needed, Weak count field waste extra memory, This does not satisfy the zero-cost abstraction. Expect additional addition strong reference count smart pointer for stdlib: Sc(Strong count),Asc(Atomic strong count).

5 Likes
2

That's not what zero-cost abstraction means — it means that the abstraction is zero cost, not that the whole thing is zero cost.

Do you have any references regarding weak references being "rarely used"? Is there any reason this can't exist in a library?

2 Likes
3

Weak references are usually used only for circular references. I hope can choose if I just want to strong reference count(Sc,Asc).

4

I have used weak references without having ever constructed circular references. The use case absolutely exists. As I asked, please provide references and explain why it can't exist in a library.

5

Weak reference count are definitely useful. I just hope there are more choices.

1 Like
6

Motivation, motivation, motivation. The two things I asked for are extremely important when trying to get something into the standard library. You're unlikely to get anywhere without answering them directly.

3 Likes
7

I mean ，The Rc Arc and Sc(new) Asc(new) coexist, Users will have more choices

1 Like
8

Sc Asc,Less memory footprint, less CPU calculation. If weak reference count are needed, think again Rc Arc. More choice and flexibility,

9

That answers neither question.

  • What sources/citations do you have that weak references are rarely used?
  • Why can this not be done in a library (that would presumably be published on crates.io)?

I will not be replying further until you answer, and I presume others won't look too highly of your comments so far. Simply saying they can coexist is frankly meaningless, as that argument applies to 99.9% of all things that exist.

4 Likes
10

I will think carefully，thanks

11

One of those crates published is servo_arc, which really is just a fork of libstd's Arc type with the weak references removed.

3 Likes
12

See also

7 Likes
13

This was an issue I ran into myself back in 2017. I'm surprised more people haven't complained about it, or that you're receiving this much pushback. It's a real issue.

I actually tried copy pasting the stdlib Rc code, but it proved to be too difficult because stdlib was using a lot of unstable features and the like.

FWIW, I don't think I've ever used Weak references in over five years of Rust coding. I did run into one case where Rc memory usage was a bottleneck.

6 Likes
14

Bit of a nitpick, and without touching the actual subject, but this actually is what zero cost abstraction means - that there is no additional cost compared to doing it without the abstraction. If you implement it directly in the code, and don't need the weak references, then you don't add that counter and don't check it - so the fact that the abstraction adds that counter and checks it means it's not zero cost.

24 Likes
15

I'd love to have Rust's Rc have a way to avoid the weak pointer, there's been several times where I homerolled buggy and UB prone code simply because the memory requirements were too high. I'd hope one day const-generics could be uor similar sed to remove Weak support entirely...

1 Like
16

Rc without Weak is definitely a reasonable data structure to have, but not necessarily in the standard library. Similar to servo_arc and its derivatives, this could be a crate.

17

Half-joking: make Rc generic over its reference count type so you can have Rc<T, Cell<usize>, ()> and Rc<T, AtomicUsize, ()> to express Rc-without-weak-refs and Arc-without-weak-refs respectively. It would be interesting to explore this as a crate at any rate.

11 Likes
18

Could even use, say, u32 on 64-bit to save some memory, since I doubt most people are actually making 4 billion copies of an Arc at the same time.

11 Likes
19

Wouldn't there still be alignment of 8 anyways due to the pointer? I suppose you could save memory if there are other 4 (or less) byte alignment members around, but that feels rare on 64-bit architectures. Basically, are there a lot of savings available by going from (16, 8) to (12, 8) (using (size, align)) in practice?

20

What pointer?

Also, if you do need Weak but only u32 counter, you have 8 bytes instead of 16.