<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am Sa., 27. Okt. 2018 um 11:07 Uhr schrieb Bertram Felgenhauer via Libraries <<a href="mailto:libraries@haskell.org">libraries@haskell.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...] We should also discuss the cost associated with mixing two functionally<br>
equivalent types in the same library, which will make the API less<br>
predictable, are likely to result in duplication in the APIs for Ptr and<br>
Addr, and will lead to more explicit type conversions with little<br>
benefit. [...]</blockquote><div><br></div><div>The more I think about it, the more serious I am about my "180 degree" proposal: Nuke Addr completely in favor of "Ptr a"/"Ptr ()". What can Addr do what a "Ptr a"/"Ptr ()" can't? Off the top of my head I would say "nothing". In most other circumstances we like generalizations, why not here? Having Addr just gives us a bigger API surface and is probably used mostly within GHC and its closely tied packages, not really "in the wild".</div><div><br></div><div>If "Ptr a" or "Ptr ()" or "Ptr Void" is the right thing to use in a specific place is always a tradeoff between ease of use, being explicit, readability, and perhaps what a corresponding C library uses. Type safety, as much as we like it, is just wishful thinking at that level, there's always castPtr (and of course the FunPtr counterparts).</div></div></div>