<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p>Actually in team, one who writes `_` match, is very useful as
      that prevents breaking code when adding new value...I can't really see any problem here. There is real world use case
    when member of team don't need to cover all cases therefore `_`.</p></div></blockquote><div>I **want** code to break when I add a new value to an ADT. I want the programmer to go through all the sites where a pattern match was done on a particular ADT and explicitly consider the impact of the new value on these sites.</div><div><br></div><div>Actual use-case -- we start with the following ADT definition and call-sites:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">data BookingStatus = Confirmed | Cancelled | Abandoned<br>computeRemainingSeats :: BookingStatus -> (...)<br>computeBilling :: BookingStatus -> (...)</blockquote><div><br></div><div>Now, assume that within `computeAvailability` only `Confirmed` is explicitly matched to result in a reduction of available seats, everything else is matched by `_` and results in a no-op. What happens when `BookingStatus` evolves to have a new value of  `ManualReview`? We want to reduce the number of seats till the manual-review of the booking is complete. However, the compiler will not force us to look at this particular call-site to evaluate this impact.</div><div><br></div><div>Another one: assume that within `computeBilling` only `Confirmed is explicitly matched to trigger an invoicing action, others are matched via `_` to a no-op. What happens when `BookingStatus` evolves to have a new value of `Refunded`, which should trigger a credit-note action? Again, the compiler is not going to help us here.</div><div><br></div><div>One may reason that this is conflation of concerns; that this should be split into **three** ADTs -- one for BookingStatus, one for AvailabilityStatus and one for BillingStatus. And pedantically this might be right. But all of these learnings evolve over time and one may not make the right decisions when writing v1 of the system. Under such circumstances, can Haskell still help in helping the programmer ensure correctness?</div><div><br></div><div>-- Saurabh.</div></div>
</div></div>