Stream: t-compiler/rust-analyzer

Topic: owo_colors


Florian Diebold (Feb 23 2021 at 10:30, on Zulip):

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.

matklad (Feb 23 2021 at 10:32, on Zulip):

cc @Jane Lusby

matklad (Feb 23 2021 at 10:33, on Zulip):

I think the problem might lie in color-eyre re-exporting owo?

matklad (Feb 23 2021 at 10:34, on Zulip):

Ie, I think blanket extensions are fine, as long as the user opts-in into using them.

matklad (Feb 23 2021 at 10:37, on Zulip):

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

Florian Diebold (Feb 23 2021 at 10:43, on Zulip):

I think even a user opting into owo_colors would probably not want to see the extension methods on every completion

Florian Diebold (Feb 23 2021 at 10:44, on Zulip):

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

matklad (Feb 23 2021 at 10:46, on Zulip):

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.

Florian Diebold (Feb 23 2021 at 10:46, on Zulip):

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

Florian Diebold (Feb 23 2021 at 10:46, on Zulip):

yeah

matklad (Feb 23 2021 at 10:46, on Zulip):

Yeah, exactly

matklad (Feb 23 2021 at 10:47, on Zulip):

An interesting lib-design approach here is to provide just one universal extension: foo.colorize().beige()

matklad (Feb 23 2021 at 10:48, on Zulip):

I am 60% sure that proper scoring (or at least scoring at all) would solve 70% of the problems here...

Florian Diebold (Feb 23 2021 at 10:48, on Zulip):

yeah, that seems like a better approach

Florian Diebold (Feb 23 2021 at 10:49, on Zulip):

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

Florian Diebold (Feb 23 2021 at 10:50, on Zulip):

although I guess the crate could introduce that and mark the existing methods as doc(hidden)

Florian Diebold (Feb 23 2021 at 10:50, on Zulip):

... or a new ide-specific attribute to hide them from completion

Florian Diebold (Feb 23 2021 at 10:55, on Zulip):

it might be nice if the completions for these methods only started showing up once you've typed three letters from it

Florian Diebold (Feb 23 2021 at 11:03, on Zulip):

but you're probably right and better ranking would mostly solve this

matklad (Feb 23 2021 at 11:05, on Zulip):

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.

Last update: Jul 27 2021 at 20:45UTC