On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert <jgilb...@mozilla.com> wrote:
> Yes I intend to write precisely that, if we ban unsigned types. > However I'm not really convinced that throwing out unsigned types is > the right move. > Note that such a class, if it performs assertions, is actually completely different than C++'s built-in unsigned types. For example: unsigned i = -1; // compiles and runs just fine with -Wall Unsigned j = -1; // would (fatally?) assert at runtime The assumption that unsigned types can't take negative values is generally false, unless if the values they're being assigned to are all asserted to be non-negative... > For instance, one of the optimizations mentioned in the linked video > seems to not mention that using (unsigned!) size_t instead of uint32_t > (like you're sort of supposed to) should also improve code generation > in the same way as using int32_t. > It does <https://youtu.be/yG1OZ69H_-o?t=2605>, it talks about the problem being caused by the mismatch between the size of the pointers (64 bits) vs the indices (32 bits) and it mentions that using 32-bit indices is common in real-world code where for example the index is stored in a data structure and the programmer chooses 32-bits to represent the index to save space in the data structure since they decide that the index can never be large enough to warrant 64-bits. > It is, however, super poignant to me that uint32_t-indexing-on-x64 is > pessimal, as that's precisely what our ns* containers (nsTArray) use > for size, /unlike/ their std::vector counterparts, which will be using > the more-optimal size_t. > > I'm not saying there's nothing wrong with unsigned types, but rather > than I feel their faults are being overblown, and the arguments > against them feel cherry-picked, which in a language like C++, is easy > to do. > As far as I understand these faults are the inherent semantics of unsigned types irrespective of whether we like them or not (their modular arithmetic semantics as well as the semantics of arithmetic with mixtures of signed and unsigned types), and the problem is that these types do something that programmers may not expect (e.g. "unsigned can't accept negative values", "unsigned values will remain (correct) positive values during arithmetic operations" etc.). The existing solutions that we have to mitigate some of these problems (CheckedInt for example) are usually helpful when the code author/reviewer are consciously thinking about these issues and otherwise we end up using them in response to bug reports. The arguments being overblown or not, IMO, is completely subjective and I doubt it is something that we will ever agree on in a discussion forum with many participants. :-) If you disagree with the semantic differences about them I'd be interested to know why. > > On Thu, Jul 4, 2019 at 4:45 PM Gerald Squelart <gsquel...@mozilla.com> > wrote: > > > > (Glad I started this discussion; thank you Nathan for the enlightening > links, I need to review all my code now!) > > > > Jeff, maybe what we need is a new value type that advertizes that it's > unsigned, but doesn't have the unwanted 2^N wrapping (and its effects on > bug-finding tools and compiler optimizations). > > `class Unsigned { int mValue; /* magic API here */ }` -- feels like > unsigned, but underneath it's all `int` arithmetics, with optional >=0 > assertions. > > Would that help? > > > > Gerald > > > > > > On Friday, July 5, 2019 at 5:35:30 AM UTC+10, Jeff Gilbert wrote: > > > That's what CheckedInt is for, and that's what we use. > > > > > > The problems webgl deals with aren't arithmatic. Arithmatic is easy. > > > (CheckedInt!) Reasoning about constraints is hard. > > > > > > We have some entrypoints where negative values are valid, and many > > > where they are not. It's really nice to have a natural way to document > > > which we expect /at compile time/. Saying "no unsigned types" really > > > throws out the baby with the bathwater for me. > > > > > > On Thu, Jul 4, 2019 at 11:46 AM Botond Ballo <bba...@mozilla.com> > wrote: > > > > > > > > On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert <jgi...@mozilla.com> > wrote: > > > > > It's a huge > > > > > help to have a compile-time constraint that values can't be > negative. > > > > > > > > The question is, how useful is that guarantee. Suppose you have some > > > > code that decrements an integer too far, past zero. Instead of having > > > > a -1 you'll have a 4294967295. Is that an improvement? Will it give > > > > the code saner behaviour than the -1? > > > > > > > > Cheers, > > > > Botond > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
