RFC: Make libstd a facade

[alexcrichton]

No description provided.

[thestinger]

The duplicate compilation of inline and/or generic functions hurts a lot too.

[alexcrichton]

Good point, I'll add a comment to this section.

[brendanzab]

I like this. What would happen to the other crates currently in the rust repo that you didn't mention? Could they be moved out into separate repositories once the cargo situation is nicer?

On a bikeshedding note, I would prefer libcore over libmini (or the previously floated libprim). core is an excellent, beautiful word that is extremely self-explanatory. You even use it in your description, "This library is meant to be the core component of all rust programs in existence." @brson has expressed concern about it being confused with thestinger/rust-core in the past, but I really think we should choose the best name for the job – one that will serve us well years into the future.

[brendanzab]

Here's a diagram of the proposed dependency graph:

[bstrie]

If we're bikeshedding, I propose libcore. Historical precedent, and you even use the word "core" in the next sentence.

[brendanzab]

See my other comment.

[bstrie]

You say above that strings "will no longer be a language item", yet here "if the string lang item is not present".

[alexcrichton]

I've clarified the wording for the first mention to be a "language feature" rather than a "language item"

[andrew-d]

This is worded really awkwardly - need to be a part, etc.?

[bstrie]

I'm concerned at the potential ramifications of leaving out strings from libmini. Perhaps traitsplosion would be acceptable in this case?

[Tobba]

Since libmini would already require weak lang items, I feel we might want to expand that system in some way so we could make liballoc pluggable instead of everything directly linking to a specific allocator (unless pluggability is already a part of the plan for liballoc, the description is a bit vague right now). This would make it possible to use libcollections, and by extension libtext, inside of a kernel, which would certainly be nice.

[cmr]

libmini doesn't require weak lang items. it just wouldn't have code that requires those lang items. if you don't use them, they aren't required.

[Tobba]

I'm pretty sure the Failure section specifically mentions that libmini requires weak lang items for failure in .unwrap?

[cmr]

I interpreted that paragraph as saying that the failure function itself will be the only "weak lang item", and that the full generalization of the feature would not be implemented.

[Tobba]

Implementing weak lang items for only a single function instead of a generic solution sounds like a bad idea to me.

[alexcrichton]

What would happen to the other crates currently in the rust repo that you didn't mention? Could they be moved out into separate repositories once the cargo situation is nicer?

I believe that for now nothing will change, and cargo is their path to moving out of the repo.

I'm concerned at the potential ramifications of leaving out strings from libmini. Perhaps traitsplosion would be acceptable in this case?

This is mostly a limitation of not knowing anything about allocation rather than a worry about traits. If we continue to keep the StrBuf and Str distinction, it may be possible for Str type to be defined in libmini because in theory none of the methods on it will allocate. This is because the definition of the type would look like:

#[lang = "str"]
pub struct Str([u8]);

This type doesn't necessarily imply any allocations, and perhaps all of the non-allocating methods could be defined in libmini and traits may be able to add some allocating-ness later on (depending on how many methods allocate).

If we don't go with the Str and StrBuf distinction, I think we'll have a hard time putting Str in libmini, but if we keep the distinction it may be plausible.

I feel we might want to expand that system in some way so we could make liballoc pluggable instead of everything directly linking to a specific allocator

I agree that this is a bit worrisome, and that was my general idea about how to do so. This is covered by the "libc is so core" unresolved question at the end, and I think that with libstd being a facade it will be possible to change this in the future without many backwards compatibility hazards (these crate structures will all be experimental, just not the reexported contents).

Implementing weak lang items for only a single function instead of a generic solution sounds like a bad idea to me.

I did not intend to generalize the idea of "weak lang items" all lang items, but rather just failure and possibly allocation. I'm not entirely sure what a generic solution would look like because many lang items are not functions (such as the traits), but this is definitely an open question about whether singling out failure/allocation is the correct way to go.

This would make it possible to use libcollections, and by extension libtext, inside of a kernel, which would certainly be nice.

I'm not entirely sure if this will ever be possible, because liballoc is built on the assumption that allocation never fails, which isn't quite true for kernel environments. User-space environments that aren't powered by libc, however, would benefit from this abstraction (switching out the default allocator).

[Tobba]

There has been some talk about weak "global" statics, which would make possibly make the libnative/libgreen situation a bit nicer and would allow for a proper pluggable liballoc.
There isn't really any reason not to make all fn lang items weak in my opinion, they're quite different from trait lang items, to which this doesn't really apply.

My proposal for weak fn lang items would be that their symbols are given special names, and default to being an external symbol in libraries. Then the compiler can complain at compile time of the application in case any are missing. Something similar could probably be applied for those weak statics.

[blaenk]

libcore is indeed clear and self-explanatory. libmetal would be very neat, the metal upon which rust forms.

[bjadamson]

I'm not entirely sure if this will ever be possible, because liballoc is built on the assumption that allocation never fails, which isn't quite true for kernel environments. User-space environments that aren't powered by libc, however, would benefit from this abstraction (switching out the default allocator).

This would end up being really sad for the kernel developers!

[mcpherrinm]

I'm pretty concerned about the fact that collections will require libc. It seems essential to me that providing a substitute allocator that doesn't depend on libc will allow libcollections and text to be used in a libc-free land. Having a more minimal "Host OS" requirement for allocation and such seems more amenable to me, like newlib's "OS stubs" https://sourceware.org/newlib/libc.html#Stubs -- a significantly smaller API to implement than all of libc.

[bharrisau]

Is it the wrong direction to go in to use weak fns and a split up like this
to handle the more complicated requests like pluggable/fail-able
allocation, integer overflow, etc.

Similar to how libmini would have Option.unwrap fail unless something like
rust_unwrap_failure() existed. A default allocator could exist in
liballoc that is only used when the alternative symbol is missing (and the
default allocator fails on allocation failure if rust_alloc_failure() is
missing).

[liigo]

blaenk: libcore is indeed clear and self-explanatory. libmetal would be very neat, the metal upon which rust forms.

libmini/libprim is a good name, libcore is a better name, libmetal is the best.

[bharrisau]

rust_stack_exhausted() is another thing that needs to live in libmetal and abort/fail, but have a bigger implementation in rustrt.

[brson]

Accepted as RFC 12, per https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-04-29

[alexcrichton]

I talked to @thestinger on IRC, and he was ok with naming the innermost library "libcore", so I will likely call it that.