Names are not type safety
I disagree, and I think this kind of fundamentalism hurts the adoption of type safety. It&#x27;s like saying that a non-machine-checkable mathematical proof is not a proof - something few working mathematicians would agree with.<p>In a well-formed program it is impossible to have a OneToFive that has not passed through toOneToFive. That&#x27;s type safety by any reasonable definition. It&#x27;s not as much type safety as you&#x27;d gain through explicitly modelling the internals, but that&#x27;s a difference of degree, not kind. Sure, using `Generic` or any number of other things lets you break your rules - but so does using `unsafeCoerce` on the constructive version.<p>I&#x27;d argue that newtypes provide a better cost&#x2F;benefit than essentially any other language feature. The author purports to embrace the idea that the type system is a tool to be used pragmatically, but that&#x27;s exactly what using a newtype does: you enforce that appropriate checks are applied to any use of any given type, but what&#x27;s &quot;appropriate&quot; is an internal concern for that module. Whereas expecting to be able to construct every domain datatype rigorously from first principles is simply not realistic in a lot of business cases; that constructive model may well be opaque or simply not exist for the domain you&#x27;re working in. (Yes, this may well mean the domain you&#x27;re working in is fundamentally incoherent - but if that incoherence is present in the real process that you&#x27;re modelling, then your model has a responsibility to faithfully reproduce it).<p>This kind of newtype use can be done <i>compositionally</i> - one module can be reasoned about without needing to understand the internals of the modules you&#x27;re depending on - which is the essence of practical, effective programming tools. A technique that only works in a &quot;closed world&quot; will always be severely limited in its applications.