Newtype wrappers

[Evan Laforge]

On Mon, Jan 14, 2013 at 3:28 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge <qdunkan at gmail.com> wrote:
>> I assume it would change from "doesn't compile" to "works" if you add
>> the required import.  It's the same as the FFI thing, right?  If you
>> don't import M (T(..)), then 'foreign ... :: T -> IO ()' gives an
>> error, but import it and coerces T to its underlying type (hopefully
>> that's a C type).
>
> This is what I thought Simon meant. If so, I don't think it's a good
> idea, as adding the import removes a compiler error in favor of a
> runtime error. If the programmer really wanted to do something this
> unsafe, she should use unsafeCoerce.

Wait, what's the runtime error?  Do you mean messing up Set's invariants?

If you as the library writer don't want to allow unsafe things, then
don't export the constructor.  Then no one can break your invariants,
even with newtype malarky.  If you as the the library user go and
explicitly import the bare Set constructor from (theoretical)
Data.Set.Unsafe, then you are in the position to break Set's internal
invariants anyway, and have already accepted the great power / great
responsibility tradeoff.