Re: Newtype wrappers

On Mon, Jan 14, 2013 at 3:28 PM, Johan Tibell wrote:

On Mon, Jan 14, 2013 at 3:18 PM, Evan Laforge 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.