Rustdoc should show which marker traits a type implements

[sfackler]

I don't think there's any way right now to find out if some type is e.g. Sync without trying to compile code that depends on it.

[huonw]

cc #13231

(this is one of the motivating reasons for opt-in built-in bounds.)

[tomjakubowski]

Will this simply fall out naturally from OIBIT?

[tomjakubowski]

Now that Copy is opt-in, the impl shows up! Huzzah!

[lilyball]

OIBITs didn't solve this. Well, it solved it for Copy, but the traits that have default impls (e.g. unsafe impl Sync for .. { }) still don't show up in rustdoc. A trait will show the negative impl if it has one, but not if it inherits its negative impl from a field.

[lilyball]

Nominating. I really think this needs to be fixed. Not having Sync/Send properly documented on types can be a real source of confusion. As this is a documentation issue, it could come after 1.0, but if we're expecting a bunch of people to start jumping into Rust as soon as 1.0 is released (which seems reasonable), then we should really try and have this done before then.

[tomjakubowski]

I think the easiest solution is to walk all the impls for the type and check whether !Sized or !Share are among them. If not, synthesize a positive impl for documentation purposes. 

—
Sent from Mailbox

On Sat, Apr 11, 2015 at 4:22 PM, Kevin Ballard notifications@github.com
wrote:

Nominating. I really think this needs to be fixed. Not having Sync/Send properly documented on types can be a real source of confusion. As this is a documentation issue, it could come after 1.0, but if we're expecting a bunch of people to start jumping into Rust as soon as 1.0 is released (which seems reasonable), then we should really try and have this done before then.

Reply to this email directly or view it on GitHub:
#17606 (comment)

[pnkfelix]

Not 1.0; P-low. (Also, not clear how to solve this, since most of the time the presence/absence of an impl is dependent on the particular type parameters you are instantiated with.)

[aturon]

Hm, I would prefer P-medium here; I think this is a very important piece of documentation to provide.

[gnzlbg]

https://www.reddit.com/r/rust/comments/46e32h/structs_not_fully_described_w_r_t_send_sync_drop/

[kscz]

As an additional urge to boost the priority on this: as someone who has been learning Rust, this is still super bewildering for Copy. i32 and i64 both implement Copy (as far as I can tell), but https://doc.rust-lang.org/nightly/std/primitive.i32.html and https://doc.rust-lang.org/std/marker/trait.Copy.html don't list the integer types as being copy-able.

This is mostly confusing when I'm trying to explain to other people the difference between a type which implements move semantics and a type which implements copy semantics; some of the core types don't expose their underlying behavior in the documentation.