@Jane Lusby and others: I just spoke with the rest of the Cargo team, and we're definitely willing to help out with questions about build-std and feature flags, if folks here are up for working towards the merge.
@Eric Huss and @Alex Crichton in particular mentioned that they'd be happy to get questions.
This is something we've wanted for a long time, and help is deeply welcome.
on the bootstrap side I am also happy to answer questions about feasibility/distribution etc
I think we're definitely moving towards pushing for a merge @Josh Triplett
the steps I forsee are
allocin its current state
Backtracein std (assuming we can later change this to a re-export of core's backtrace type)
im assuming that 2 is fine because no matter what when we merge things together that would presumably resolve any issues, assuming there are even any issues about moving things around
which I doubt there are given that I think we've done that before
that all sounds relatively reasonable
I think the major hurdle is going to be chasing down upstream projects that are currently "real" dependencies of std and converting those to
#[path = ... ] deps of std, or trying to push on a compiler change that would permit more ergonomic "copy/paste this code in" that doesn't require changes in the upstream logic
a couple of my friends have pointed out that they think package local orphan rule violators might be the better approach in the long run
where you could group alloc/std/core into one package but as different crates ( i think im not mixing those up) and the orphan rules would be applied to the group rather than each individual crate
I'd also be happy to go down this path, I don't really have a strong preference
tho the latter approach seems like it might have large benefits downstream as well
I also remain unconvinced that literally combining the crates is the way to go here vs. adding a std-only-for-now switch. I think boats had concerns about this approach? I may be misremembering
I do think it's going to be quite hard to get the unification to work out nicely, though probably a one-time cost mostly
Jumping in from an out of band conversation with @Jane Lusby . I have some reservations about merging the stdlibs, and in particular I think motivating it by the orphan rule is a mistake because the problems with the orphan rule here are quite general.
This has been discussed in the past, but, a lot of projects are conceptually "multiple crates, one package", where the "package" is intended to be versioned as a single thing, but is split into many crates to aid in conditional compilation, features, etc. Notably, there are _many_ cases where rust forces you into splitting crates especially when you want to use features, and it ends up being easier to do this. I know that Rain is looking into this kind of thing.
There's a case to be made for local orphan violations within the same package. I've been in situations where i've needed this quite often, and it's one of the main reasons the orphan rules gets annoying -- when it gets in the way where there is _actually no danger_ but it's entirely due to how you chose to slice your code.
FWIW, there are multiple other reasons to want to merge the crates; this isn't just about the orphan rule. More generally, there's a desire to be able to compile one crate with feature flags that may be finer-grained than the existing std or alloc.
I wouldn't want to see the error-handling project commit everything to making that work as the solution. More that if we agree we want this change anyway, and it's just a matter of implementation effort, then having people who are willing to do the work would help.
another example is it'd be great to use simd in libcore, but we it's difficult today because cpu feature detection is in libstd
@Charles Ellis O'Riley Jr. If you want to
impl SomeTrait for SomeType, you must either be the crate that provides
SomeTrait or the crate that provides
SomeType, to a first approximation.
(It gets a little more complicated with types that have generic parameters, but that's the key concept.)
impl of a trait for a type where you don't own either the trait or the type is called an orphan
Josh, first, thank you for the explanation. Second, I have much to learn.l:grinning:.
I'm not going to focus on this that much just yet but once we've mostly worked thru the backtrace stabilization issue I think I'll try to go back and create a summary of the problems we're trying to solve and the solutions that are available so we can figure out how we want to move forward to get error into core
related discussion https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Why.20is.20HashMap.20in.20std.20and.20not.20alloc.3F
We have tons of APIs that want this in std and not all of them are coherence related, some are inherent methods, for example
changing the coherence boundary to be larger than the crate would make rust coherence depend on the build system, I'm really not compelled by any proposal to make the language potentially incoherent without cargo
Last updated: Jan 29 2022 at 11:01 UTC