RFC 48 not updated to reflect meeting decision

[lilyball]

According to the meeting notes on RFC 48 (PR #136), at the end, @nikomatsakis says that he wants to make a change for private supertraits. Presumably this means changing the RFC to allow them. However, the RFC was merged without any such change.

[nikomatsakis]

Actually I was unsure whether I wanted to make a change for supertraits. But you have reminded me of one concrete concern that I did have and forgot to voice. I wanted to permit private traits in type parameter bound lists. I don't see the harm (it doesn't expose values or types that would otherwise be hidden, I believe) and there is a concrete use case: permitting you to limit the types to which a function can be applied to a set you completely control. We use this (or could use this) for atomic integers. 

With respect to private supertraits my concern is that we would need to specify the interaction with method privacy. I held back on recommending a change because it seemed rather complicated. 

Niko

-------- Original message --------
From: Kevin Ballard notifications@github.com
Date:08/12/2014 18:38 (GMT-05:00)
To: rust-lang/rfcs rfcs@noreply.github.com
Cc: Niko Matsakis niko@alum.mit.edu
Subject: [rfcs] RFC 48 not updated to reflect meeting decision (#196)

According to the meeting notes on RFC 48 (PR #136), at the end, @nikomatsakis says that he wants to make a change for private supertraits. Presumably this means changing the RFC to allow them. However, the RFC was merged without any such change.

—
Reply to this email directly or view it on GitHub.

[nikomatsakis]

Never mind, having discussed more with @aturon and thought about this I think I've decided I don't feel any change is needed.