Janky APIs: Arc::strong_count and Arc::count

[A248]

Faithful to your suggestion in #128 , I took a brief look at this crate's API for places that are awkward or should be deprecated.

Arc::strong_count and Arc::count are a good example; these redundant methods somehow became included in triomphe over the years.

I'll keep my eyes peeled and, when I have more time, maybe add more comments to this issue.

[A248]

Deprecated methods

Some deprecated (previously unsound) APIs for MaybeUninit data could be removed:

triomphe/src/arc.rs

Lines 464 to 467 in 1a6249e

	#[deprecated(
	since = "0.1.7",
	note = "this function previously was UB and now panics for non-unique `Arc`s. Use `UniqueArc::write` instead."
	)]

triomphe/src/arc.rs

Lines 494 to 497 in 1a6249e

	#[deprecated(
	since = "0.1.8",
	note = "this function previously was UB and now panics for non-unique `Arc`s. Use `UniqueArc` or `get_mut` instead."
	)]

CoerceUnsized

I just realized/remembered that the standard Rust trait CoerceUnsized is still a nightly/unstable API. Because of this, triomphe can't perform unsizing coercions. I checked this using a test. For example, std::sync::Arc works here, but triomphe::Arc doesn't:

let my_type: [u8; 3] = [0, 4, 1];
let arc_it: Arc<[u8]> = Arc::new(my_type);

Instead, triomphe is has optional integration with the unsize crate, which provides a stable mechanism for unsizing coercions.

This is probably something that should be addressed before triomphe gets to version 1.0, or if the crate API is to be improved.

UniqueArc::shareable

Maybe this method should be better named, according to typical conventions. Something like into_arc feels more rusty to me.

triomphe/src/unique_arc.rs

Line 94 in 1a6249e

pub fn shareable(self) -> Arc<T> {

[Manishearth]

Hmm, could you please file separate issues for this? Have them all have a Breaking: prefix on their title.

For strong/weak count, we can deprecate them now, and we should just have a catch-all "Breaking: Remove deprecated APIs" issue

[A248]

Roger that.

As for the reference count, which of strong_count and count should be kept, and which should be removed? I know triomphe doesn't support weak references, so this is only a matter of naming.

I think it makes more sense to provide count() reflecting the crate design. strong_count can be deprecated/removed. If discoverability is a concern for people used to the standard library, then a doc-alias would make the other name appear on docs.rs, which I think was the original intention behind strong_count anyway.

[Manishearth]

I think just count() should be kept, with the others being deprecated. A doc alias sounds like a good idea!