@Alex Crichton why do you think the libc traits have to be behind a feature at all ? I don't really follow the rationale.
I mean, during the RFC it was argued that this should depend on what impact these features would have, and @Susurrus went out of its way to actually implement this, and measure the effect of these features on compile-times.
The effect is negligible, ~1 extra second of compile time in @Susurrus benchmarks. I think that having this as an off by default single feature like @SimonSapin suggests could be "ok" (don't pay for what you don't use), but I am not sure if its worth it because it's something else in the matrix that we have to test, gets less use if not everybody has it enabled, all code would be full of
cfg_attrs, etc. and all of this just to shave 1 second in compile times "once".
And even then,
libc is probably compiled in parallel with other crates, so that ~1 extra second might turn out to be even less than that in practice.
@gnzlbg for me it's just being conservative, we can always turn it on by default later
libc is just so tricky to change
I agree there's no technical known reason to not turn on by default
I figure we can see what the experience is if they're turned off
yeah, i would prefer to say that this has to be implemented behind a single feature first, but than then we should decide whether we keep it that way, or not
the moment the cargo feature is "stable", we have to keep it around forever
I think w/e we publish to crates.io must be considered insta-stable though
implementing this behind one cargo feature per-trait as @David Tolnay suggests feels a bit overkill TBH
I don't think we have much of an out to avoiding that
it doesn't matter too much though?
they're small names and small features
I think @Susurrus wanted to send a single PR implementing this for the whole library at once
sure? but that's still fine to have a feature-per-trait
cfg_attr per trait per type, I mean, can be done, but looks like too much work for too little win
(FWIW, it'd be nice if there was link to context here, because without this discussion is rather meaningless to observers^^)
@gnzlbg there's just one location this is being done though? in one macro?
#[cfg_attr(feature = "trait-eq", derive(Eq))] #[cfg_attr(feature = "trait-..."), derive(...)] ... we can put it all behind macros, but we would be having all these features to shave a fraction of that 1 extra second
I'm not necessarily worried about the exact time today
but moreso about the long-term-future of libc
yes, i think that would all go in the
as we continue to add more and more types
like this was a clear win in winapi
winapi is huge
if libc turns into
winapi, then everybody will be paying for a lot of stuff they don't use anyways, just check
winapi feature flags
they have dozens and dozens of features
I guess I just don't understand why there's pushback here
it shoudl be very easy to implement this
and we can change it in the future
what's the downside?
the downside is that's just more features to test in the matrix for little win
we definitely don't need to test this on all platforms, that's just overkill
it'd just be like one extra entry in one place
we have to build with this on all platforms at least
not run the libc-tests (that's pointless I think), but check that we build properly
some of the
repr attributes interact poorly with deriving some traits
structs cannot derive
Ok? Can you take these arguments to the RFC? I'm not convinced but others might
in any case, I'm fine with putting all these traits behind a single feature, but one per trait feels overkill to me
i didn't consider your argument that this allow us to not offer this "by default" in the future if
libc grows enough that this would become a problem