search

smessmer / binary-layout

The binary-layout library allows type-safe, inplace, zero-copy access to structured binary data. You define a custom data layout and give it a slice of binary data, and it will allow you to read and write the fields defined in the layout from the binary data without having to copy any of the data. It's similar to transmuting to/from a #[repr(packed)] struct, but much safer.
Apache License 2.0
66 stars 9 forks source link

deprecated attribute is ignored on define_layout! macro #20

Closed billtong closed 1 year ago

billtong commented 2 years ago 
#[deprecated]
define_layout!(tlv_header, LittleEndian, {
    tlv_type: u16,
    tlv_size: u16,
});

When compile it shows the warning.

the built-in attribute deprecated will be ignored, since it's applied to the macro invocation define_layout

I'd like to know if there is any solution for this.

smessmer commented 1 year ago

The implementation of this crate uses macro_rules! and as far as I know, there is no way for such macros to check whether there is a #[deprecated] annotation above their invocation site. There might be a way with procedural macros, I'm not sure, but even if there is, it wouldn't be worth rewriting this whole crate just to get this one feature.

Another potential option would be to make this a parameter, something like

define_layout!(tlv_header, LittleEndian, deprecated, {...})

but to be honest, I find this syntax too complicated and not worth the benefit.

One thing you could do is wrap tlv_header::View into your own struct, use that in your codebase instead of using tlv_header::View directly, and mark that one as deprecated:

// This is private and not exported from your module
define_layout!(tlv_header, LittleEndian, {
    tlv_type: u16,
    tlv_size: u16,
});

// And this is exported
#[deprecated]
pub struct TlvHeader(tlv_header::View)

I'm closing this issue for now because I don't see an ergonomic way to implement this feature within the library, but feel free to reopen if you have ideas.

billtong commented 1 year ago

Thanks for the detailed explanation! Wrap it in a struct tuple looks reasonable to me.