Document EIIs of integer types (IComparable/IConvertible) #3499
Conversation
carlossanlop
added
new-content
There was a problem hiding this comment.
This looks great @carlossanlop
I had one question. Once we resolve that, I'll 
| </item> | ||
| <item> | ||
| <term>Zero</term> | ||
| <description>This instance is equal to <paramref name="value" />.</description> |
There was a problem hiding this comment.
On the interface, we've described this as follows:
This current instance occurs in the same position in the sort order as
value.
For all the integral types, those two descriptions mean the same. I'll approve this, and you can decide if you want to use the same consistent language. (This comment applies to all pages in this PR)
There was a problem hiding this comment.
Hey @BillWagner would you mind elaborating a bit more? I'm not sure where you got that description from, so I'm not understanding your suggestion here.
In case it helps: I got all this text from <Member MemberName="CompareTo"> in this same file (line 181), and simply added the extra remark about the EII.
There was a problem hiding this comment.
@carlossanlop The language I quoted above is from the IComparable<T> interface page, in the remarks section.
For all the types in this PR, CompareTo returns 0 if and only if the two instances are equal. That's not true for all types. (Imagine ordering events by date. Two events on the same date would be in the same location in the sort order, but may not be equal.)
For these types, that distinction doesn't matter. I just want to make sure we're consistent and explicit on how we make this decision.
There was a problem hiding this comment.
Oh I see what you mean. I think the descriptions are fine for these int types, they were adapter for their specific behavior.
mairaw
removed
the
waiting-on-reviews
Int16, Int32, Int64, UInt16, UInt32, UInt64 all implement these two methods: