<div dir="ltr"><div>Compatibility issues aside, is there any reason newtypes aren't a good solution here? You could get away with just one:</div><div><br></div><div>{-# LANGUAGE FlexibleInstances #-}</div><div><br></div>
<div>newtype FasterInsecureHashing a = FIH { unFIH :: a }</div><div><br></div><div>instance Hashable Int where </div><div> hashWithSalt = ...stuff...</div><div><br></div><div>instance Hashable (FasterInsecureHashing Int) where</div>
<div> hash = unFIH</div><div><br></div><div>instance Hashable ByteString where </div><div> hashWithSalt = ...SipHash...</div><div><br></div><div>instance Hashable (FasterInsecureHashing ByteString) where</div><div> hashWithSalt = ...CityHash...</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 5:43 PM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Mar 19, 2013 at 9:19 AM, Thomas Schilling <span dir="ltr"><<a href="mailto:nominolo@googlemail.com" target="_blank">nominolo@googlemail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Oh, I just realised that this proposal is to include the older version<br>
of hashable. In principle, I'm not against that, but I do wonder what<br>
the upgrade path is. I don't think the performance problems can be<br>
fixed in general -- that's just the price of security. So it becomes<br>
critical what the upgrade path looks like. Do users get a slowdown of<br>
2x by default and then have to manually make it faster again if<br>
something is not security sensitive? Do users have to explicitly opt<br>
in for security (a bad default, IMO)? Do we have any idea how that<br>
switch may affect the API?</blockquote><div><br></div></div><div>From an API standpoints, users of unordered-containers will be unaffected by any changes to hashable and people who write Hashable instances are unlikely to be affected either, as long as they write their instances in terms of hashWithSalt.</div>
<div><br></div><div>From a performance standpoint, it depends on what we decide to make the default behavior of hashable be and for what types (e.g. we could use SIpHash for string types but a simple hash for Int-like types). This is the issue that's not already settled and the reason I'm holding hashable back to 1.1 for the platform. I'm leaning towards fast by-default as hashing is just one of many security issues web frameworks already consciously have to deal with. It's also an issue which have many alternative fixes, which don't require a stronger hash function.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-- Johan</div><div><br></div></font></span></div>
<br></blockquote></div><br><br clear="all"><br>-- <br>Your ship was destroyed in a monadic eruption.
</div></div>