Remove default features for 1.0
JelteF opened this issue · 6 comments
This library is growing more and more, and most people only use a few of the provided derives. So I think a better default might be to enable none of the features by default. It seems especially useful because some of the less commonly used derives depend on other crates again too, like convert_case.
@tyranron any opinion on this?
This would obviously be a breaking change, so I'd want to do this for 1.0 if we indeed want to go this way.
@JelteF the main concern I dislike with it is that "just give me all the derives" is a very common case, and not always people are happy to opt-in derives one-by-one. But I think that we can cover this case just by introducing a full/all feature, like tokio does. So, overall, I'd vote to do this change.
@tyranron I'm not sure about turning full feature off by default. This will leave crate completely empty by default and drive users to turn those features one-by-one as they hit complier error with every new macro used. I don't think this will be a pleasant experience. I would argue that you should start with full and maybe optimise it way later, once you actually care about build times. Moreover I find benefits quite small, as majority of the build time of this crate will be syn and quote and I don't really know how each macro affects build time. Did someone actually benchmark it?
Given we now have an std feature, I think there's an extra reason for this: Otherwise people using std would always have to add std feature as well when trying to enable a single feature.
derive_more = {version = '1.0', default-features = false, features = ['try_from', 'std']}vs
derive_more = {version = '1.0', features = ['try_from']}Also I did some basic benchmarks and derive_more-impl crate compilation takes a significant amount of time, which is lowered a lot when building only a single feature. Going 4.5s to 1.3s:
cargo build --timings --jobs 1
cargo build --timings --jobs 1 --no-default-features --features as_ref
Bikeshedding question: Should the feature to enable all derives be called full or all? I'm leaning to full since that's what tokio has too.