@WG-prioritization/alerts issue #80303 has been requested for prioritization.
If this is a
T-libs issue we probably shouldn't prioritize it
Why? We prioritize other T-libs issues.
That is an implementation issue
Here this needs a decision from
Well, we could prioritize the issue at hand, that
VecDeque is hashed differently after a few rotates when it should not
Well this seems to be a libs-impl issue as well.
We should still prioritize even if it needs a decision. It will help T-libs figure out which things that they need to decide on are high priority.
I think P-high might be right. (Or maybe P-medium, but not sure.)
Note that this works with the standard
It doesn't work with the hasher from
Huh, didn't realize that. Can you add that to the issue?
Also, is it
Hash's fault that
ahash isn't working?
The point that cuviper made in their comment was that depending on the
T-libs decision, this might either be a bug in
VecDeque, the int types, or in
Which is why I'd wait for
T-libs decision here
Issue #80303's prioritization request has been removed.
I-prioritize and added
Léo Lanteri Thauvin said:
@Léo Lanteri Thauvin how does the
i-needs-decision label work? I mean what are the effects of applying it? Example: are some notifications broadcasted? Is anyone picking them up later or any automatic collection mechanism?
That's up to
ok thanks :-)
T-lang uses it
We might want to ping a
T-libs member to know
Nevermind, they have been pinged on the issue already
I'll send a message in #t-libs