Remove prelude dependency for range notation; rename FullRange

[aturon]

The range notation currently desugars directly to uses of e.g. RangeFrom and requires these structs to be present in the prelude.

In addition, the FullRange struct should probably be called RangeFull for conventions/consistency.

[aturon]

cc @nick29581

Nominating for 1.0 beta, P-backcompat-lang.

[nrc]

As far as I see it, there are two options: we either put RangeFull in the prelude and desugar to RangeFull or we don't and we desugar to ::core::ops::RangeFull, both are equally easy to implement, the former is the current implementation. Note that we can't make RangeFull a lang item because we desugar in the parser, not later in the compiler (there is an issue for making lang items available in libsyntax, but I can't find it right now and it's a fair bit of work, so unlikely to be done soon).

For most users the two approaches are identical. Not having anything in the prelude is an advantage of the second approach.

The difference is for users who aren't using the prelude. Off the bat, the former approach does not work, and the latter one does (assuming they are using libcore). If they are not using libcore, then under the second approach, they are screwed (they could I guess create their own lib called core with ops in it and a RangeFull struct in that, but that kind of sucks).

Without a prelude, users would have to provide a RangeFull struct in scope, presumably with an import in each file. This is sub-optimal, but it does work even if they are not using libcore.

Finally, there is the overriding case. The first approach allows users to override RangeFull with their own struct, whereas the second approach does not. (Because only prelude items can be shadowed). However, since we don't use the struct for anything other than a place holder, I don't really see any benefit of overriding it.

On balance, it seems that the second approach is slightly better, the only people it really sucks for are those running without libcore. Do we expect that to be a sizeable group or not?

[nrc]

And another thought: approach 2 is easier to future proof - I'm not exactly clear on how the stability stuff would work here, but could we mark RangeFull as unstable? We would allow stable use only via the range syntax, and one day when we have libsyntax lang items, we could make it a lang item, rather than hard coded. I guess this would not work for people implementing slicing who have to use RangeFull in their impls.

Perhaps, even if we mark it stable, we could still change to using a lang item in the future without breaking anyone's code, so it is backwards compatible? Whereas approach 1 would be backwards incompatible because users could rely on it being in the prelude.

[lambda-fairy]

I think using ::core::ops::RangeFull would be more consistent, given that the std macros (println! and try! and friends) all use absolute paths too.

[aturon]

@nick29581 I pretty much agree with your thinking here -- it should be a lang item in the long run, but welding it to a path for now should allow us to future-proof that change. (And no-core scenarios are not considered stable anyway).

(I think running without core is very unusual, because core imposes so few constraints.)

We do need to stabilize the various structs so that people can provide custom impls of traits for them, and so on. But I agree that making it a lang item should be a fine change, especially since no-core is not considered stable.

cc @alexcrichton

[alexcrichton]

I agree that an absolute path is the best way forward for now.

[pnkfelix]

1.0 beta, P-backcompat-libs

[nrc]

So, I implemented this (expand to ::core::ops::RangeFull. One downside I had not anticipated is that now every crate has to extern crate core so that core is in scope. Are we OK with that? Alternatively, we could re-export RangeFull from std, but then expanding to ::std::ops::RangeFull would fail for anyone building no_std (including a bunch of our libs).

Any other ideas?

[alexcrichton]

We should stick to expanding to ::std::ops::RangeFull and not inject extern crate core, we can work on the no_std case later (this is only one pain point in a long line). I believe @kmc's $crate for macros should work well here (to be adapted at a later date)