#994: add 'unsafeCoerce' to a standard location in the hierarchical libraries
-------------------------------------------+--------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version:
Severity: normal | Resolution:
Keywords: | Difficulty: Easy (1 hr)
Testcase: | Architecture: Unknown
Os: Unknown |
-------------------------------------------+--------------------------------
Comment (by simonmar):
I would rather that the unsafe modules were placed in the hierarchy at a
place determined by their functionality, eg. following the example of
`System.IO.Unsafe`. The hierarchy naming is supposed to primarily reflect
''functionality'', and I argue that the notion of "unsafety" should be
secondary to what the function actually does in terms of naming the
module.
To summarise: I would much rather see `Data.Array.Unsafe` than
`Unsafe.Data.Array`. I admit I don't have a good idea for where
`unsafeCoerce` should go, though - it doesn't fall into any existing
categories.
On the existence of `unsafeCoerce` itself, I'm happy to see it in a
standard place, but we should be very careful not to guarantee
''anything'' about what it does. For example, GHC has some strange
restrictions on what you can ''unsafeCoerce'', and it's possible to crash
the compiler by using it.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/994>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
