Apols if I'm overstating the case, but let me try to clear things up.
Roles are not in place to provide a "safe" cheap coerce. Roles are in place to _prevent_ an unsoundness with newtype deriving in the presence of type families. They also happen to _allow_ a cheaper coerce. The unsoundness is fixed by roles, with or without specific role annotations, because the necessary roles for type-safety (preventing segfault) are inferred/enforced regardless.
With or without roles, in the past, it has been possible to circumvent certain mechanisms of abstraction by using newtype deriving. Explicit roles now _allow_ library writers to, for the first time, to enforce these abstraction mechanisms more strongly than in the past. We also happen to have a new "coerce" that will not segfault, and _if_ role annotations are correct, will respect representation-hiding. If libraries do _not_ get updated with roles, the "worst" that can happen is that their abstractions are precisely as deliberately circumventable as in the past, although there is now an "easy" function provided that makes this circumvention more straightforward.
So I feel it is "better" to enforce representation-hiding through proper usage of roles. However, it is also no great sin to _not_ enforce it for some span of time, since all that doing so prevents is a rather (at the moment) esoteric mechanism for developers to shoot themselves in the foot -- a mechanism that in a slightly different form has existed all along.
-g On 3/24/14, 10:44 AM, Mark Lentczner wrote:
The major problem with this feature is that it is massively global in scope. This is extremely rare for GHC extensions (Safe comes to mind)... and with good reason: It is very very expensive. The motivating case here, a compiler checked safe zero-cost coerce, seems way out of proportion to the cost: Careful review of every library abstract type, and addition of *three+* lines of source (remember, this must be CPP guarded, so you have to add CPP extension on to every file, too).
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
