#15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5268 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): the discussion started in https://mail.haskell.org/pipermail/libraries/2018-October/028997.html (https://mail.haskell.org/pipermail/libraries/2018-October/thread.html) and continued through november https://mail.haskell.org/pipermail/libraries/2018-November/thread.html i'll write up more notes later, but ultimately the conclusion seems to be : 1. theres not really any examples where the code becomes simpler/safer/more performant with Address in base and usage thereof 2. there are valid/ real issues with some Ptr based interfaces and they could be improved. (and some confusion about why/best/practicies, and in one case the mistaken belief that all `Ptr a` values will conform to the Storable type class representation) there were ~ 3 people arguing for inclusion in base, but in my own opinion there wasn't a case substantiating their utility. (and some of the exemplar changes they suggested would needless break existing code without fixing any underlying issue, as best i could tell) Punchline: theres definitely a genuine need for better tooling around pointers to make its way into the ecosystem and perhaps eventually base, but this Adddress work doesn't accomplish that -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15812#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler