Show equivalence of redefined List.In and List.NoDup with Coq stdlib versions

Maintainer
What is the point of this, why would one ever use the ones from the stdlib? There are hardly no lemmas about it, and you won't get the ∈ notations.

Owner
I searched for lemmas relating
Forall
to something about list membership, foundList.Forall_forall
, and then spent 15min trying to do anything with theIn
I got out of that. Having this lemma would have meant I would have completed my proof at least 10min quicker.Of course, I should have used the
Forall_forall
from std++, but there's no way I could have known. I'd rather have a notperfectlyclean, but working proof after 5min than spend 20min to find the "right" proof. 
Maintainer
But then, why would you use
In
and notelem_of
? 
Maintainer
I don't understand why it was difficult to find something relating
Forall
to list membership then:Search elem_of Forall. elem_of_mapM_fmap: ... elem_of_mapM_Forall: ... Forall_forall: ∀ (A : Type) (P : A → Prop) (l : list A), Forall P l ↔ (∀ x : A, x ∈ l → P x)

Owner
I did first
SearchAbout Forall
or so, stumbled upon Coq'sForall_forall
, and then I spent 15min doingSearchAbout In <something>
in dozens of variations (and other, related avenues) and found nothing. My mistake was using Coq'sForall_forall
instead of the one from std++. I don't say the one from std++ cannot be found, but for me, it showed the one for Coq first, and I had no way to know that I was not supposed to use it. 
Maintainer
We can blacklist stuff from the standard lib that we have redefined for search? Would that solve your problem?

Owner
Also, generally, people having some experience with Coq will know
In
and may even doSearchAbout Forall In
, which will not even bring up anything from std++. It's not nice to lead them into a dead end like that. I honestly don't think it is a good idea to even redefine these notions from the standard library, that's just asking for exactly the kind of trouble I am having. But if we do redefine it, then at the very least we should provide some way to convert between the two worlds in that split ecosystem we are creating. There will always be the case of some lemma usingIn
not having been proven with∈
. 
Owner
We can blacklist stuff from the standard lib that we have redefined for search? Would that solve your problem?
It would help to make the first mistake less likely, but it may also be confusing. And I would still insist on having these equivalence lemmas somewhere.

Maintainer
Actually, never mind, that won't work. The blacklist functionality AFAIK only allows one to do some basic matching on lemma names.