My expectation matches Brandon's, that making roles default to nominal would break lots of code and therefore have a higher cost than defaulting to representational (well, phantom actually, but that's a rarer case).
As for issuing a warning, I've thought about this some, but I don't know the right place to detect and issue it. Do we want to warn about any parameterized datatype definition without a role annotation? (That's a lot of them!) Do we want to warn only about abstractly-exported datatypes without role annotations? (But, what about types exported concretely from an internal, hidden module and then re-exported abstractly?) Do we want to warn at use sites? (But then the warning is more about the library than the use site.) It's all quite thorny, and several of us have thought about this all for a while with no strong conclusion.
So, the best thing we came up with is this: Libraries that wish to export abstract data types must do two things:
1. Manage export lists carefully.
2. Use role annotations.
A better question might be how to get the word out about the above.
Whether or not `coerce` is "unsafe from a correctness perspective" depends on your definition of correctness:
- If you care only about type safety, then `coerce` is most certainly safe.
- If you believe that a type's roles are what its author intended, then `coerce` is most certainly safe.
- If you believe that authors may omit critical role annotations and are worried about breaking abstraction, then `coerce` is not safe.
Note that 7.8 does not actually give users a new way to break abstractions -- GeneralizedNewtypeDeriving has been around for a while. What 7.8 provides is a way to break abstractions more easily (`coerce`) and a way to prevent this from happening (role annotations).
Richard
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries