this is an ... interesting problem. I'm inclined to say that creating such huge extension traits implemented for almost all types should maybe be discouraged; but maybe we also need to provide some way (attribute) of 'fixing' this in existing cases. I'm not a fan of any setting that requires listing specific traits or functions. I wonder what other people think about this though.
cc @Jane Lusby
I think the problem might lie in
Ie, I think blanket extensions are fine, as long as the user opts-in into using them.
But yeah, it's hard to say what's the ideal behavior here. Not suggesting to flyimport the trait would be wrong, I think.
I guess, once we have a scoring system in place, we can score
impl<T> Trait for T really low
I think even a user opting into owo_colors would probably not want to see the extension methods on every completion
also, I don't even think this is just about flyimport -- even if you've
used the trait it'd get pretty annoying in the whole file
This feels like an inherent tradeoff to me you will be annoyed by seeing methods everywhere, but you also will be annoyed by not seeing the method where you want to.
or I mean, a user using owo_colors would want to see the methods in some situations (inside println) but not in most others, but of course the problem is that we can't really magically know which situations that are
An interesting lib-design approach here is to provide just one universal extension:
I am 60% sure that proper scoring (or at least scoring at all) would solve 70% of the problems here...
yeah, that seems like a better approach
and that's kind of what I mean by discouraging that kind of extension traits, but it of course doesn't help with the existing crate
although I guess the crate could introduce that and mark the existing methods as
... or a new ide-specific attribute to hide them from completion
it might be nice if the completions for these methods only started showing up once you've typed three letters from it
but you're probably right and better ranking would mostly solve this
but I actually like the attribute idea -- we can use an attribute to control ranking. Llike
#[completion(unlikely)]. Though it seems more robust to just infer those based on usages.