I've done exactly this a number of times. The approach I generally take is to define a completely new ADT, mark the old one as deprecated, and then simply plough through the compiler warnings and errors, which is a mostly mechanical process.

On occasion I've written a (temporary) injection from the old datatype into the new one which lets you make the changes piecemeal (by topologically sorting the usages) which is nice as if there's any risk of making a mistake then tools like `git bisect` can help you find the slip in the sea of otherwise identical changes. Doesn't always work smoothly but it's often ok.

This also has the advantage that you don't have to fix all the usages in third-party code or dependent libraries straight away. The deprecation step need not be immediate, depending on how stable your API is supposed to be.

Cheers,

David

On 31 Jan 2017 06:48, "Saurabh Nanda" <saurabhnanda@gmail.com> wrote:
Btw, what about the other approach -- listing all possible occurrences of type X throughout the app?

-- Saurabh.

On Tue, Jan 31, 2017 at 12:15 PM, Saurabh Nanda <saurabhnanda@gmail.com> wrote:
We want this at my company too, so we don't write fall-through cases.

That's a short-term workaround, yes. However it doesn't fit into Haskell's overall story of language-enforced correctness.

-- Saurabh.



--

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.