qtypes: add support for Qt alias types that don't match #904
Conversation
ahayzen-kdab
force-pushed
the
882-add-qtypes
branch
from
e8826f5
to
e409d32
Compare
ahayzen-kdab
force-pushed
the
882-add-qtypes
branch
from
e409d32
to
e5daff8
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #904 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 71 71
Lines 11949 11949
=========================================
Hits 11949 11949 ☔ View full report in Codecov by Sentry. |
ahayzen-kdab
force-pushed
the
882-add-qtypes
branch
2 times, most recently
from
debf9b7
to
79cc8fe
Compare
crates/cxx-qt-lib/src/core/qtypes.rs
Outdated
| #[cxx_name = "qint64"] | ||
| type QInt64 = super::QInt64; |
There was a problem hiding this comment.
In Rust should we be calling these QInt64 and QUInt64 or should we copy Qt and use lowercase qint64 and quint64 ? 🤔
ahayzen-kdab
force-pushed
the
882-add-qtypes
branch
3 times, most recently
from
6a21207
to
c67af09
Compare
ahayzen-kdab
changed the title
Some times don't match the Rust types so add these missing types. Closes KDAB#882
ahayzen-kdab
force-pushed
the
882-add-qtypes
branch
from
c67af09
to
709d25d
Compare
There was a problem hiding this comment.
Overall this looks good.
Naming wise I would just copy Qts casing (so lowercase). These types are quiet "fundamental types", which even in Rust are lowercase (i64, isize, etc.).
A sort-off open question is still how many operations we want to support on these...
Do we basically just enable From/Into and call it a day, or do we want to have support for using the type more directly, like support for +-*/ on qint64...
For now it's probably good enough if we just have them convertable to their inner type, but something to keep in mind.
On the same note: Maybe we don't want to support Deref on these types?
It may be weird if you call e.g. abs on qint64, but get an i64 back...
And now it would be a breaking change for us to add our own abs method that returns qint64...
So it seems like limiting the API to just From/To with some derives is maybe best?
|
|
||
| /// Typedef for long long int. This type is guaranteed to be 64-bit on all platforms supported by Qt. | ||
| #[repr(transparent)] | ||
| #[derive(Default, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)] |
There was a problem hiding this comment.
I would add Clone and Copy to this list as well...
| /// Typedef for long long int. This type is guaranteed to be 64-bit on all platforms supported by Qt. | ||
| #[repr(transparent)] | ||
| #[derive(Default, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)] | ||
| pub struct QInt64(i64); |
There was a problem hiding this comment.
Let's go with qint64 here. No need to rename the type. It's still a sort off "fundamental type" like i64, which is also lowercase.
|
|
||
| /// Integral type for representing pointers in a signed integer (useful for hashing, etc.). | ||
| #[repr(transparent)] | ||
| #[derive(Default, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)] |
There was a problem hiding this comment.
Again, let's add Copy and Clone to that list :)
| /// | ||
| /// Note that configuring Qt with -qreal float is not supported | ||
| #[repr(transparent)] | ||
| #[derive(Default, Debug, PartialEq, PartialOrd)] |
|
|
||
| /// Typedef for unsigned long long int. This type is guaranteed to be 64-bit on all platforms supported by Qt. | ||
| #[repr(transparent)] | ||
| #[derive(Default, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)] |
|
|
||
| /// Integral type for representing pointers in an unsigned integer (useful for hashing, etc.). | ||
| #[repr(transparent)] | ||
| #[derive(Default, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)] |
| /// Integral type providing Posix' ssize_t for all platforms. | ||
| /// | ||
| /// This type is guaranteed to be the same size as a size_t on all platforms supported by Qt. | ||
| #[derive(Default, Debug, Hash, PartialEq, Eq, PartialOrd, Ord)] |
Closes #882