Why would `Poll::is_ready` need to be const?

I noticed this in the release notes for 1.49:

The following previously stable methods are now const .

I am struggling to understand how you would use these functions in a const context though, which makes me think my understanding of the use case for const functions must be lacking.

How would you use these functions in a const context?

I found this tracking ticket but that doesn't really explain why.

Thanks!

I don't think it would be useful from within the task system, but it's possible someone is using or will use Poll for something slightly different that is available in a const context. I think the motivation for making these standard library functions const is more for consistency than an actual use case - it would be weird if Option::is_none was const but Poll::is_ready wasn't.

After some more searching, I am reaching the conclusion that it would be purely for consistency, rather than driven by any likely use case.

That does seem a little strange to me - I assume that once you have marked the function as const, it would be hard to go back on that if you later find that you need to update the logic in a way that means it can no longer be const, so I would have thought you would only mark a function in std as const if there was a likely use case.

While that's true, I can't imagine any reason -- not even a contrived one -- that is_foo on an enum with a Foo variant would ever do anything except check that it's that variant, which is always and fundamentally something that's totally fine in const.

For more complicated things, sure, but trivial little helper methods like that should never do anything impure.

2 Likes