Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Ability to construct Weak<T> from RcBorrow<T> #58

Closed
yvt opened this issue May 24, 2020 · 6 comments · Fixed by #59
Closed

Feature request: Ability to construct Weak<T> from RcBorrow<T> #58

yvt opened this issue May 24, 2020 · 6 comments · Fixed by #59
Labels
enhancement New feature or request

Comments

@yvt
Copy link

yvt commented May 24, 2020

Currently, one has to first convert [A]rcBorrow to [A]rc before obtaining Weak. It would be great if Weak could be constructed directly without this extra step.

@CAD97
Copy link
Owner

CAD97 commented May 25, 2020

Yeah, I agree, this is useful. #59 implements the functionality.

In retrospect, I wish downgrade returned a Weak instead of &'a T. Do you have any suggestions for what to call this function?

@yvt
Copy link
Author

yvt commented May 25, 2020

do you have any other suggestions for what this method should be called?

Sorry, I don't have any. It's really a shame that downgrade is already taken.

How do you feel about redoing the naming scheme in the next major version (0.2.x)? This would be a breaking change, but the impact of introducing breaking changes tends to accumulate as you try to defer it, which makes it important to iron out any API design issues at the earliest moment possible (this needs to be balanced against annoyance to users, though). I think this is the point of pre-1.0 versions.

@CAD97
Copy link
Owner

CAD97 commented May 25, 2020

rc-borrow is already v1.0. All of pointer-utils is: it was important to me to signal that these utilities are "production worthy," so I published them at 1.0.

On top of this, [A]RcBorrow is a type intended to be used in public APIs. This makes breaking changes more problematic, as they necessarily cascade into people who use rc-borrow, rather than being self-contained.

The point is that rc-borrow doesn't need breaking changes, and it won't need breaking changes; the core functionality works as intended and doesn't need API-breaking changes.

It'll be sad to lose downgrade, but maybe deprecating downgrade and adding [in]to_weak and [in]to_ref wouldn't be too bad.

@yvt
Copy link
Author

yvt commented May 25, 2020

Hmm, I wonder why I thought rc-borrow was still at 0.1.x. Anyway, In that case, I agree that the ship has already sailed.

It'll be sad to lose downgrade, but maybe deprecating downgrade and adding [in]to_weak and [in]to_ref wouldn't be too bad.

Considering the circumstances, this sounds good to me, except that I feel as_ref is more appropriate according to the style guide.

@bors bors bot closed this as completed in #59 May 26, 2020
@CAD97
Copy link
Owner

CAD97 commented May 26, 2020

I just added to_weak in #59 and will hopefully publish this soon-ish. (My workspace helper is acting up right now, though, so it might be a bit.)

I'll consider renaming downgrade in the future, but to_weak is nonproblematic to add right now.

@CAD97
Copy link
Owner

CAD97 commented May 27, 2020

Published as v1.3.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants