triage: I-nominated
triage: beta-nomianted
triage: P-low
After discussion with @alexcrichton, my conclusion was that the remaining problems are low priority, with the exception of the issues discussed (and hopefully addressed) in RFC https://github.com/rust-lang/rfcs/pull/1296.
My understanding of the situation is roughly as follows (feel free to correct me if you feel I am mistaken):
.o
triage: P-medium
We discussed this last week in the language subteam meeting. Our conclusion was that there is (potentially) an issue here where the desired semantics are not entirely clear. It is backwards incompatible to fix it but deemed low risk, because the bad scenario is when one is trying to “add to” the default set that obey a particular trait (or remove further from the negative set, I suppose).
Some notes from our discussion:
The intent of an impl like this is somewhat unclear. Why did one write the impl in the first place? Was the goal to cover a case that the default rules would have excluded? Or was it perhaps to narrow down the default rules to a smaller set of acceptable cases (which kind of “opts out” by “opting in”)? The latter is the current semantics; it does seem plausible that a naive read of the code might think that the impl was listing out the cases that are Sync, versus adding to an implicit set. A short-term fix we might use is to try and report errors if the impl is “unnecessary”. Overall though our conclusion was the current semantics ought to be revisited with specialization in mind, since there is a lot of overlap (no pun intended!) between the situation here and that of specialization.
Sync
I'm also going to lower the triage. It seems unlikely that anyone would *intentionally* abuse this, and I think we'll be able to fix this without undue anger or breakage out there in the wild.
Permalink to this digest
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
