NonZero lang item.

[luqmana]

No description provided.

[reem]

What happens if I put a non-pointer, non-integral type in NonZero?

[luqmana]

With the initial implementation in rust-lang/rust#19536 it doesn't do anything special. It would just act as any other struct there and the optimization wouldn't kick in.

[reem]

That seems like a reasonable approach, but I think we may want to make it an error to use NonZero for non-supported types.

[luqmana]

Hmm, we could probably actually do that just by limiting the types constructor will accept.

[reem]

I think it should be baked into the compiler, because there is no trait for the types we'd like to fit here. We could possibly write a marker-only trait with unsafe traits and default traits.

[killercup]

Rendered

[Thiez]

This appears to be just a special case for a more general case of being able to limit the possible values a type can take. For instance, we know &x cannot be a null pointer, that is, let ptr = &x as *const _ as uint, ptr != 0. But we also know that ptr != 1, and ptr != 2... In fact, unless we're writing an operating system it should be correct to assume that the entire 4k page starting at address zero is unmapped, so ptr >= 4096. So really we could have a type NonZeroTo4096.

Could Rust benefit from being able to limit ranges more than just NonZero?

[Manishearth]

@Thiez Sort of, in the sense that enums of the form

enum Foo<T> {
Bar(NonZeroTo4096<T>),
Baz,
Quux,
// up to 4094 more variants
}

would be optimized. But this doesn't seem like a rather common usage.

[nikomatsakis]

@luqmana Obviously, this is a good thing to have. We discussed this in triage today. Current thinking is that we would like to close this RFC for now. There is already a tracking issue #278 indicating that this is a desirable feature to add to rust at some point after 1.0. It seems that there are enough use cases here that it's worth trying to think through the public-facing interface in more detail.

However, it's still worth optimizing common cases like Option<Rc<int>> and so on. Therefore, we'd like to land your patch, but ensure that the NonZero lang item is not publicly exported from libstd. This way it cannot be used without a feature gate (since accessing items directly from crates in the facade will be feature-gated, as is declaring lang items manually).

What do you think?

[luqmana]

@nikomatsakis That works for me. As for not exporting the lang item, initially I just placed it in core::ptr and used it from libcollections & liballoc. But due to libstd have a pub use core::ptr it would be available through std. I'm pretty sure there isn't a way to say export everything but this right now.

[sfackler]

Seems like you can shove it in its own module.

[pythonesque]

@Manishearth I actually do think it would be a useful feature to have. I have wanted it quite often.

[nikomatsakis]

In accordance with #499 (comment), closing this PR.