[Development] What's our policy on changing the result of qHash(T, 0) between major releases?

Marc Mutz marc.mutz at qt.io
Wed Feb 7 07:02:11 CET 2024


On 05.02.24 23:42, Thiago Macieira wrote:
> On Monday, 5 February 2024 01:36:39 PST Marc Mutz via Development wrote:
>> I've always understood it such that we as Qt must preserve the property
>> that the hash for equal elements is equal within _one_ run of _one_
>> process. This means you can use the hash in I/O in any way. That's why
>> we have qt_hash, which you _can_ (and do) use in I/O (but is private
>> API, AFAIK). I never thought that a hash seed of zero would change that,
>> but of course users may have come to depend on this (Hyrum's Law), so a
>> [ChangeLog] would be in order.
> 
> In commit e3f05981cbeb0b7721f960ef88effa77be2af5ce, I added this comment to
> qHashBits:
>      // mix in the length as a secondary seed. For seed == 0, seed2 must be
>      // size, to match what we used to do prior to Qt 6.2.
> 
> Which is why I am asking now, because making this change would go against that
> comment. But there was no discussion in the change about whether this was
> correct or not. It seems I just write it like that.
> 
> However, that was qHashBits(). The change I'm talking about is
> qHash(QLatin1StringView), specifically so it won't call qHashBits().

As someone who argues that qHash("Hello"_L1) be restored to 
qHash(u"Hello"_s) after this relation was broken somewhere in Qt 5, how 
could I argue against it? :)

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B



More information about the Development mailing list