Skip to content

Always use MaybeUninit and stop using nodrop fallback, prepare next release #129

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

Merged
merged 5 commits into from
Sep 2, 2019

Conversation

bluss
Copy link
Owner

@bluss bluss commented Sep 1, 2019

Switch to using MaybeUninit for everything (no more nodrop fallback for older Rust versions).

Use std::mem::MaybeUninit and stop using nodrop as a fallback.
This means we require Rust 1.36.

And prepare release notes partially for the next release.
Update ArrayExt methods in anticipation of next release.

@bluss
Copy link
Owner Author

bluss commented Sep 1, 2019

Completely sidenote, but arrayvec's test suite passes with experimental const generics (not part of the PR). However one of my arrayvec applications has unexplained crashes that I haven't been able to reduce right now, with the const generics arrayvec, so it's not exactly ready.

@c410-f3r
Copy link
Contributor

c410-f3r commented Sep 1, 2019

@bluss

You mean that you are already working with const generic stuff?

@bluss
Copy link
Owner Author

bluss commented Sep 1, 2019

@c410-f3r It was a 10 line patch to try it, it's not more than that to implement. So yes and no. I've tried it, and evaluated it and the conclusion so far is in the previous comment, no further work right now.

@c410-f3r
Copy link
Contributor

c410-f3r commented Sep 1, 2019

@bluss

Ok, thanks! Good to know since I was about to start working on this to create a PR.

@bluss
Copy link
Owner Author

bluss commented Sep 1, 2019

@c410-f3r on closer look it might be related to MaybeUninit changes — so it's worth trying. And it's easy to drop in const generics by changing the Array trait impls, but I guess we actually want to change the parameterization of ArrayVec itself to actually do it, which is more work.

Keep in mind that we can't really merge anything until const generics are stable - maybe there's a good way to have it as a preview unstable feature, but we'll need to use some care. An unstable new Array impl could be an ok middle ground.

@c410-f3r
Copy link
Contributor

c410-f3r commented Sep 1, 2019

@c410-f3r on closer look it might be related to MaybeUninit changes — so it's worth trying. And it's easy to drop in const generics by changing the Array trait impls, but I guess we actually want to change the parameterization of ArrayVec itself to actually do it, which is more work.

Great. I will start look into it in the next few days.

Keep in mind that we can't really merge anything until const generics are stable - maybe there's a good way to have it as a preview unstable feature, but we'll need to use some care. An unstable new Array impl could be an ok middle ground.

I was basically thinking of doing the same thing I did in smallvec, which is a new unstable const_generics feature controlled by a macro invocation.
Hope I can soon provide a PR to give a better understanding of the overall changes.

This is a nicer and simpler interface to expose, since the ref to uninit
array to pointer cast is not usable anyway (it's historic now, arrayvec
itself does not use it anymore).
Use std::mem::MaybeUninit and stop using nodrop as a fallback.
This means we require Rust 1.36
@bluss
Copy link
Owner Author

bluss commented Sep 1, 2019

@c410-f3r Please don't publish the same kind of PR here as the one to smallvec - keep separate changes separate and well contained, and you'll save yourself from heartbreak. We're as likely to be conservative here as there, about what changes we want to incorporate.

@bluss bluss merged commit c7424b8 into master Sep 2, 2019
@bluss bluss deleted the prepare-0.5 branch September 2, 2019 20:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants