What is your use case for this? This has come up before (#428).

As described in the linked PR I’m not a big fan of the proposed API as it makes mixing Standard and Extended IDs easy, something that usually is not intended.

I just wanted to retrieve the raw ID for quick debugging/printing purposes (after I could not simpy print it with defmt). I did not care about the Standard ID / Extended ID distinction in that case, and I found it weird/unintuitive that I had to unmatch the value.
Basically, it is just an API that I expected to be there.

After going through the mentioned thread for a bit, I can see the point of intentionally making the mixup harder.
The possible mixup of standard and extended ID is something that could be mentioned inside the documentation as well, but I guess this becomes a question about how to design the API and whether to expose methods like this which might increase convenience, but also introduce bugs when not used with care. I have not worked with more complex CAN buses yet with both standard and extended frames (just getting started) where this might become an issue.

What about a raw_id_unchecked method with better documentation?

after I could not simpy print it with defmt

Have you enabled defmt-0.3 feature?

The latest main has defmt support, but not 0.4.1. A new release for embedded-can is required

@timokroeger I updated the PR

Looks reasonable to me but pinging @rust-embedded/hal for review