Closed ActuallyHappening closed 12 months ago
Renetcode
is a standalone crate, and shouldn't share any code with renet
. Is there a reason why you want to make this change?
This change ensures that properly typed arguments are used to be more explicit in intent, to ensure better type safety. It is also more consistent, as ClientId
and ClientID
were used in renet
and renetcode
respectively but were distinct types, which was confusing and could be improved to use a shared type.
If you try to define the ClientId
in renet
, it cannot be used in renetcode
(cyclic deps). If you try to define ClientId
in renetcode
, renet
must unconditionally depend on it as part of renet
's public API uses ClientId
, but its actual transport layer is optional. Thus, a new dependency must be added if both renet
and renetcode
are to use the same type.
Hey,
This seems a bit overkill for what essentially is a u64. And renetcode
is a standalone crate, don't want to renet/renetcode to share a crate just for the ClientId type.
I decided to remove the alias in renetcode
and just use an u64
(e9566792b9ed110b6d2551a2971ed48c3e14bb9f), it didn't add very much. Was not public and not even used in all places.
OK all good
Thanks so much for this awesome ecosystem of crates!
This PR extends #103 by introducing the
ClientId
type intorenetcode
. #108 for why a new package was needed, there would be a cyclic dependency ifrenetcode
depended on a type fromrenet
sincerenet
depends onrenetcode
.This PR also bumps all the package versions, so this would be a major release which is SemVer correct since all the examples would have to be updated. Note:
renet_core
::ClientId is publicly exported from bothrenet
andrenetcode
.Also, to satisfy
clippy
warnings about 'this loop never actually loops' were fixed in the relevant examples.