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.m...@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
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
