#9220: type roles for unboxed arrays -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.1 (other) | 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 rwbarton): Replying to [comment:6 goldfire]:
If I understand correctly, then, a representational role will allow users to get out-of-bounds errors, right? This would happen in the contrived scenario in comment:3.
You won't actually get an out-of-bounds ''error'', you'll simply read outside the memory area allocated to the array (which could cause a segfault, or leak other data, or just return nonsense). Regarding `UArray` specifically, I believe it's true that all the different existing instances of `IArray UArray` are for non- representationally equal types (although under the hood many are actually represented identically, e.g. `data Word8 = W8# Word#`, `data Word16 = W16# Word#`; I believe these are still not inter-`coerce`-ible, though). And in order to write your own `IArray` instance you have to define functions with names like `unsafeAt`. So a representational role for `UArray` would be justifiable if ensuring that the in-array representation is identical is considered to be part of the contract when defining an `IArray` instance for a newtype. (One that would be satisfied automatically by GND.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9220#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler