Make RcOrArc a documented type alias instead of a direct reexport

[Expurple]

PR Info

• Closes: none
• Dependencies: none
• Dependents: none

New Features

Bug Fixes

Breaking Changes

Changes

(probably not changelog-worthy)

• Made RcOrArc a documented type alias instead of a direct reexport.

It used to show full documentation for Rc/Arc. I find it weird.

Now, it documents what RcOrArc actually is and how to control the representation.

[tyt2y3]

nice. but apart from the docs, is there any functional difference between an alias and re-export? I am asking so as to not unknowingly introduced a breaking change

[Expurple]

cargo-semver-checks doesn't report anything:

sea-query$ git status
On branch rc-or-arc-type-alias
Your branch is up to date with 'origin/rc-or-arc-type-alias'.

nothing to commit, working tree clean

sea-query$ cargo semver-checks --version
cargo-semver-checks 0.40.0

sea-query$ cargo semver-checks --release-type patch --baseline-rev master --all-features
     Cloning master
    Building sea-query v0.32.3 (current)
       Built [   2.118s] (current)
     Parsing sea-query v0.32.3 (current)
      Parsed [   0.065s] (current)
    Building sea-query v0.32.3 (baseline)
       Built [   2.105s] (baseline)
     Parsing sea-query v0.32.3 (baseline)
      Parsed [   0.062s] (baseline)
    Checking sea-query v0.32.3 -> v0.32.3 (assume patch change)
     Checked [   0.224s] 148 checks: 148 pass, 0 skip
     Summary no semver update required
    Finished [  13.238s] sea-query

A quick Google search found a few gotchas with type aliases (1, 2), apparently not applicable here.

I think, technically this is a breaking change on nightly Rust, because my type alias doesn't have the second type parameter (A = Global). That type parameter is unstable, so it's inaccessible on stable Rust. It means that there's no breaking change for stable Rust users. But it also means that I can't forward it by default, because it wouldn't compile on stable. It would have to be gated behind an opt-in #[cfg(feature = "nightly")], or something like that. Which is still breaking, because it's opt-in.

However, I wouldn't worry about this, because this breakage is really niche:

• It affects only nightly Rust users who use custom allocators with RcOrArc.
• Which doesn't make sense, because the rest of sea_query assumes the global allocator and doesn't allow to change it. E.g., these two types wrap RcOrArc and hardcode it to use the global allocator:

  pub struct SeaRc<I>(pub(crate) RcOrArc<I>)
  where
      I: ?Sized;

  pub enum ColumnType {
      Array(RcOrArc<ColumnType>),
      // ..
  }

• So, this only affects nightly Rust users who use custom allocators with RcOrArc, but only for their own purposes, without passing custom-allocated RcOrArc into sea_query???

[tyt2y3]

thank you. I trust your judgement!

[tyt2y3]

sorry I forgot to click merge.

[github-actions]

🎉 Released In 0.32.5 🎉

Thank you everyone for the contribution!
This feature is now available in the latest release. Now is a good time to upgrade!
Your participation is what makes us unique; your adoption is what drives us forward.
You can support SeaQL 🌊 by starring our repos, sharing our libraries and becoming a sponsor ⭐.