feat: wrapping traits

[enitrat]

Added traits for wrapping arithmetic operations, based on the overflowing operations.
Removed reexporting from the ops module, to only have it at the num::traits level.

---

This change is 

[orizi]

Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion (waiting on @enitrat)

---

corelib/src/integer.cairo line 3013 at r1 (raw file):

/// WrappingAdd implementations
impl TWrappingAdd<T, +core::num::traits::OverflowingAdd<T>> of core::num::traits::WrappingAdd<T> {

for must types these implementations are less efficient than direct implementations currently.
the generic implementation will actually block efficient implementation - which is a problem.

[orizi]

Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion (waiting on @enitrat)

---

corelib/src/integer.cairo line 3013 at r1 (raw file):

Previously, orizi wrote…

for must types these implementations are less efficient than direct implementations currently.
the generic implementation will actually block efficient implementation - which is a problem.

you may instead add these as an internal mod overflowing_based near the trait, and use it directly for all the reexported types here.

[enitrat]

Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion (waiting on @orizi)

---

corelib/src/integer.cairo line 3013 at r1 (raw file):

the generic implementation will actually block efficient implementation

I'm not sure I understand: what's the problem with this approach and why would it make it less effician than adding these in an internal module if I reexport it with impl aliases?

[orizi]

Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion (waiting on @enitrat)

---

corelib/src/integer.cairo line 3013 at r1 (raw file):

Previously, enitrat (Mathieu) wrote…

the generic implementation will actually block efficient implementation

I'm not sure I understand: what's the problem with this approach and why would it make it less effician than adding these in an internal module if I reexport it with impl aliases?

for example - for multiplication - the implementation would have just been wide mult + masking, but this already does more - and this implementation catches all, so cannot be improved.

may be ok just because it is within integer.cairo - but i still rather be more careful here.

[enitrat]

Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion (waiting on @orizi)

---

corelib/src/integer.cairo line 3013 at r1 (raw file):

Previously, orizi wrote…

for example - for multiplication - the implementation would have just been wide mult + masking, but this already does more - and this implementation catches all, so cannot be improved.

may be ok just because it is within integer.cairo - but i still rather be more careful here.

Ok - got it. If I understand well I should rewrite them directly instead of being overflow_based, because there are extra unused return parameters adding unnecessary extra steps and we should aim for efficiency.

I can just write the full implementation directly instead of relying on Overflowing traits if that's better.

[orizi]

Reviewed 3 of 5 files at r1, 2 of 2 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @enitrat)

a discussion (no related file):
@gilbens-starkware for 2nd eye.

---

[gilbens-starkware]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @enitrat)