Moved Ascii to core and collection

[Kimundi]

No description provided.

[Kimundi]

Not sure why the build failed, but it doesn't seem related to this change, and make check passes locally.

[lilyball]

LGTM, r=me once others have had time to voice any potential disagreement.

[brson]

@alexcrichton @aturon do you have opinions about this? It seems like a move in the right direction, but I know the ascii module is not widely loved.

[alexcrichton]

I personally don't believe that all candidate modules for libcore should necessarily move to libcore. For example time::duration is not being added to libcore when it certainly could.

In general I feel that libcore should serve as being the core library for almost all rust programs in existence, including the functionality they all need. I'm not totally convinced that ascii falls into that category, and I agree with @brson that this module is likely in need of some love to see some improvements.

That being said, the public API is entirely the same, so with the facade we're entirely at liberty to make any decision at any time and revert it at any time in the future!

[lilyball]

@alexcrichton I agree that not everything that technically can go in libcore should. time::duration is a good example. That said, there have been suggestions in the past that ascii could be moved to libcore, as basic character processing is something that is a fairly fundamental operation. Unicode character processing doesn't make so much sense to put in libcore, but I feel like ASCII is common enough and self-contained enough to be a good fit.

[Kimundi]

Right, my feeling is if str lives in core, then so should Ascii, seeing how it is a subset of UTF8.

In fact part of the motivation of this PR was that I was writing code in core::str, and really would like to express the "is asciii" invariant on a type system level for some operations.

Whether the casting traits associated with Ascii really have to move to core and collections is a different question, but the core type at least belongs there in my opinion.

[liigo]

+1 move Ascii to core::str

[aturon]

I am somewhat torn about this. I think we should probably work on some explicit criteria for what goes in libcore. At the moment, the contents fall into roughly the following categories:

• Primitive types and some basic operations on them.
• Intrinsics.
• Traits for operators and other special traits.
• A small assortment of types/traits that all Rust code should agree on: iterators, collection traits, comparisons, Option/Result, core atomic types

There are a few other things, like finally, that don't really fall into these categories and could perhaps be moved out.

Personally, I don't buy the argument that because str lives in core, ascii should too. The str type is a primitive type, with special syntactic support. And even so, a lot of its supporting infrastructure lives elsewhere, notably libunicode. You could make a similar argument about c_str, and other notions of string.

Given that ascii is not really a primitive/core feature, the question to me is whether it's crucial for all Rust code to agree on a single notion of ASCII character. I think the answer is "no", when compared to things like Option or Iterator that show up in a much larger proportion of Rust code and APIs.

So I guess in the end, I'd rather not make this promotion. I'm happy to have this functionality live only in libstd.

[lilyball]

@aturon ASCII is a rather fundamental way of working with strings. It seems unfortunate to require liballoc and all the rest of libstd just to be able to work with ASCII characters. Surely embedded systems or kernels have a need to do work with ASCII occasionally.

However, I am sympathetic to the idea that libcore should be restricted in what it contains. On that topic, I have two questions:

1. Do you think libcore currently contains modules that it shouldn't?
2. Do you think there are other modules that may be wanted by embedded systems/kernels and don't depend on liballoc, but aren't suitable for libcore?

If the answer to either of those questions is "yes", then perhaps we should have a libcoreextra (or libcoreutil or some other name) that contains things that could technically go into libcore but are maybe not considered fundamental and universal enough to be put there.

Otherwise, if ascii is the only module that fits the bill, I'd say just put it in libcore and call it a day. We don't need a libascii, and putting it in libunicode doesn't make sense (programs should not be required to embed unicode tables just to work with ASCII).

[brson]

Closing per @aturon's stated reasons, with which I agree.