Skip to content

Conversation

Nemo157
Copy link
Contributor

@Nemo157 Nemo157 commented Aug 17, 2018

This is mostly not that useful, except for futures-test where we want to have statics available for the more trivial test wakers for better ergonomics.

r? @cramertj

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 17, 2018
/// on the current thread.
#[inline]
pub unsafe fn new(inner: NonNull<dyn UnsafeWake>) -> Self {
pub const unsafe fn new(inner: NonNull<dyn UnsafeWake>) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add the rustc_const_unstable attribute and a test enabling the feature and using it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #47562 for an example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I managed to get an example going. Unfortunately writing that example made me realise that this isn't usable for what I want anyway since it's !Send + !Sync so can't go in a static, as I don't know of any other usecases for this to be const I'm gonna close this and try to find an alternative.

One thing I noticed while adding the example, rustc_const_unstable requires a stable/unstable directly on the item being annotated, LocalWaker is in an unstable module so doesn't have a direct annotation, is there some reason the attribute needs to be directly on the item instead of inheriting from its parent scope?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there some reason the attribute needs to be directly on the item instead of inheriting from its parent scope?

Does implementation lazyness count as a reason?

Most newly added const fns already had a stability attribute, so it was less hazzle to add an attribute to those that didn't have it than to correctly implement the attribute

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation lazyness is the best reason.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<Joke about Haskell has been elided due to laziness>

@Nemo157 Nemo157 closed this Aug 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants