Improve the OOP ABI

[Siarhei Siamashka]

On Tuesday, 23 January 2024 at 03:34:23 UTC, Jonathan M Davis 
wrote:
> On Monday, January 22, 2024 7:33:33 PM MST Siarhei Siamashka 
> via Digitalmars-d wrote:
>> On Monday, 22 January 2024 at 23:31:16 UTC, deadalnix wrote:
>> > On Monday, 22 January 2024 at 22:44:20 UTC, Walter Bright 
>> > wrote:
>> >> On 1/22/2024 1:11 PM, Bruce Carneal wrote:
>> >>> Blake3 might be worth a look.  It's reportedly faster and 
>> >>> stronger than md5.
>> >>>
>> >>> https://github.com/BLAKE3-team/BLAKE3
>> >>
>> >> Thanks for the tip. I don't know how to evaluate a hash 
>> >> function for uniqueness.
>> >
>> > Blake is > 128 bits, so I don't think there is anything 
>> > really interesting there anyways.
>>
>> It's probably possible to take just the first (or last) 128 
>> bits
>> of BLAKE3 and the result might have better properties than MD5
>> (considering that MD5 is broken). There are some answers 
>> related
>> to "truncated hash" on the Internet about SHA-256, but any
>> cryptographically secure hash is likely to be similar in this
>> aspect:
>> https://crypto.stackexchange.com/questions/161/should-i-use-the-first-or-las
>> t-bits-from-a-sha-256-hash/163#163
>
> Why on earth would we care if the hash is secure in this 
> context? We obviously care about the likelihood of collisions, 
> and if that's high enough (which does not seem to be the case 
> for md5), then the hash is unsuitable for comparing class 
> names, but why would crytographic security matter when 
> comparing class names in the compiler?

BLAKE3 was mentioned because it is allegedly faster than MD5 
(this still needs to be confirmed). You can take as many bits of 
its output as you need and being too large is not a problem. 
Having high likelihood of collisions would have made it a bad 
hash from the security standpoint, so you don't need to worry 
about collisions for your use case either.