Now that rust is getting const generics (and default const generics seem to be behind a feature), any thoughts on adding a const B: usize = 6 const parameter to BTreeMap?
It's actually impossible to have both type and const parameters with defaults (the compiler complains no matter what), but that looks like a simple oversight.
This might let applications tune the memory consumption and performance of BTreeMap.
(note that defaulted const generics are only parsed at the moment: we added this very recently, and as soon as you enable the feature gate it'll ICE everywhere)
Could that be mitigated by giving the struct a new name when the parameter is added and defining a type alias for the old name that maintains the original parameter list?
Logistically, the first thing you might want to check is whether a const generic parameter can be marked #[unstable]. If that works then this is more plausible. If not, I'm not sure that this is "obvious" enough to go in insta-stable.
IIRC that was discussed for things like Box's allocator parameter, and it was decided it wasn't a good way forward. I forget exactly why -- maybe because the ___WithAlloc name would show in error messages?
What would be the general policy here? I bet there are more tweakables here and there which we can expose this way. For example, we can treat Vec’s growth factor the same.
My gut feeling is that this’ll give needless choice with little benefit. I’d rather have the standard library pick the optimal B automatically, based on the sizeof of key.
I like this idea the best; it's like the Context parameter of Future::poll. Since Context leaves open the possibility of adding more fields later on, it allows forward compatibility for when someone decides that more knobs are needed.