Я бы посоветовал против неумеренного использования полиморфных вариантов. Они хорошо выглядят на бумаге, но более гибкий вывод и подтип вернут вас назад в любое время. Когда я использую полиморфные варианты, я стараюсь убедиться, что каждое использование снабжено точным ограничивающим выражением типа.
Я бы предложил вернуться и модифицировать ваш старый код, как это кажется естественным. Если вы написали свой код с учетом расширяемости и, в частности, избежали использования _ -паттернов типа bool2, то компилятор предупредит вас о любом месте, где делается предположение, что существует только два конструктора. Эта обратная связь компилятора о модификации типа очень полезна, так как это механическая помощь, чтобы сделать вашу программу правильной.
Этот способ, конечно, имеет некоторые недостатки. Одним из них является то, что изменение определения типа, а затем изменение каждого варианта использования может не сработать с вашей обычной практикой тестирования компиляции: если вы сделаете это на большой базе кода, у вас будет много важных вещей, которые нужно сделать до компиляции проекта снова чисто (и, следовательно, может быть проверено). Вы можете разделить вашу модификацию на несколько патчей в вашей системе контроля версий, но это означает, что некоторые промежуточные зафиксированные состояния не компилируются, что не очень приятно. Другая возможность состоит в том, чтобы изменить это место только для добавления сбоя во время выполнения (| Third_one -> assert false), тогда у вас будет скомпилированный код, и вы можете исправить эти сбои, как они происходят во время выполнения во время тестирования приложения. Но я все еще думаю, что обратная связь со статическим компилятором - хорошая помощь для поддержки кода.
Существует также опция оборачивания алгебраического типа данных в «расширенный алгебраический тип данных» type bool3 = New | Old of bool2, который обсуждается в ссылке, которую вы даете в качестве комментария ответа Мартина. Это может быть хорошим способом перехода от одного типа данных к другому, не прерывая компиляцию, но в долгосрочной перспективе это будет болезненно, особенно если вы кладете больше этих расширений друг на друга.
Конечно, в некоторых ситуациях действительно потребуется способ расширения типа данных путем добавления кода вместо модификации кода таким образом, чтобы он был статически безопасным, простым для компиляции, запуска и тестирования и эффективным во время выполнения. Это пример проблемы выражения , для которой они являются различными решениями, одним из которых является полиморфный вариант. Но в общем случае вам не нужна дополнительная гибкость, связанная только с добавлением кода, и она не стоит дополнительной сложности соответствующих языковых функций, поэтому я бы посоветовал придерживаться простых старых типов вариантов, если это явно не огромный усиление делать по-другому.
PS: в отношении полиморфных вариантов и их связи с проблемой выражения обязательной статьей является Повторное использование кода через полиморфные варианты Жака Гаррига.