Period does not implement operator ==

[JvSSD]

I happened to create two zero-length periods two different ways to test for equality like so:
var period1 = Period.Zero;
var period2 = PeriodPattern.Roundtrip.Parse("P0D").Value;

Doing period1 == period2 compiles just fine. However, the result was not what I expected. This returns false, not true. On the other hand, doing period1.Equals(period2) does return the expected result of true.

[jskeet]

Nicely found. That's a surprise.

Adding the operators is technically a breaking change, but will only make broken code fail, I suspect. It won't break binary compatibility, although it will change the meaning of existing code.

@malcolmr any thoughts?

[jskeet]

Labelled as both a bug and an enhancement in that violating the principle of least surprise is arguably a bug :)

[malcolmr]

I think it's reasonable to call this a bugfix and then also call it out in the migration guide.

(Does this also affect equivalence for any dictionary or set-like containers, or do they all use IComparable?)

Is there any way to verify that we haven't missed any operators from any other types?

[jskeet]

Set-like things should all be using Equals, which is already implemented.

I could write a test for "classes that implement IEquatable<T> but don't overload ==". There may be some that are deliberate, but we could always put those on an allow-list.

[jskeet]

Have now automated this via a unit test. The current type that implement IEquatable<T> but not operator == are:

• Period
• TimeZones.Cldr.MapZone
• ZoneInterval

MapZone is sufficiently complex that I don't think it's appropriate to overload ==, but the other two are okay. (I suspect we mostly have MapZone.Equals for the sake of testing.)