Since we know all of the tag types ahead of time, there's no reason we couldn't preserve the format-specific items (or the entire tag itself) in an immutable way inside the Tag, using an enum.
This would be a global setting, like allocation_limit, which would be enabled by default.
On any call to Tag::re_map(), the format-specific items would be discarded.
Since we know all of the tag types ahead of time, there's no reason we couldn't preserve the format-specific items (or the entire tag itself) in an immutable way inside the
Tag, using anenum.allocation_limit, which would be enabled by default.Tag::re_map(), the format-specific items would be discarded.Tag::save_to, the format-specific write implementation would simplychainthe items to the iterator, for example: https://github.com/Serial-ATA/lofty-rs/blob/be749a48a3f3cf6c7a0dd91f158ac96be3bbea78/src/id3/v2/tag.rs#L1312This would make #288 obsolete, and save users from metadata loss, due to the majority simply using the generic API for reads and writes.
This would not affect
{split, merge}_tag. It will only be used forInto::<Tag>::into(format_specific_tag), for example: https://github.com/Serial-ATA/lofty-rs/blob/be749a48a3f3cf6c7a0dd91f158ac96be3bbea78/src/id3/v2/tag.rs#L1285-L1289Not sure of this now, but this could also remove the need for
ItemKey::Unknown, allowing it to finally beCopy. This has been a pain point forever.