#9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Simon, I have code in production where the contract for a newtype and the wrapper you want to have enforced here doesn't hold -- in particular cases where the newtype _solely exists_ to create a Storable with different alignment and sizing properties. This comes up for all sorts of things, packed colors, bit arrays, etc, structures folks are marshaling for std140 compliance to/from OpenGL uniform buffers... It seems dangerous to me to tie a contract about the behavior of a user defineable class to representability. If we're letting users define Storable instances is seems strange to me to conflate the two notions of representation (bit representation of Storable) and the heap representation for GHC. This puts me very much in the Plan A camp, personally. Plan B it seems could just lead to segfaults for existing user instances out there. With Ptr we're basically handing the user a live grenade, they know handling it wrong can lead to segfaults, and they do so with due care. With an Array I don't think there is any such expectation of unsafety, and folks are expecting things to 'just work'. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9220#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler