Paul Ganssle <p.gans...@gmail.com> added the comment:
> Just my two cents, this isn't just "some compilers". Everything from gcc, > msvc, C# to the rust compiler complain about this sort of code. As they > should, this is effectively dead code. They complain because most of the time it's a sign that people were intending to use a signed integer, and it's an indicator that they may be susceptible to integer overflow. In this case, it was a deliberate choice to include the extra check knowing it's dead code, because it is essentially a machine-checked documentation of the bounds of that particular variable. > I think the more pragmatic way to enforce and document this assumption would > be to have a unit test that actually checks that the constructor fails with > "negative" days. It'll continue to fail right now as its interpretation as an > unsigned int will be large and it will start failing if someone changes this > to a signed type. This would be helpful, but it's not an either-or situation. This particular thing would be tricky to write a targeted unit test for, because it's a very deep implementation detail. Such a unit test would also be quite physically separated from the code in question, whereas if we left the code as-is, we'd never see this type of bug, and if we added a static assertion we'd be told at compile time exactly what is wrong. The biggest problem here is the fact that we cannot disable compiler warnings when complying with them makes the code less readable and/or less robust. This makes compiler warnings less useful, since it changes the calculus around whether or not it's worth it to introduce a new compiler warning. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42660> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
