Hello @AlexTMjugador! That is an interesting idea, but I wonder whether we can introduce this without a semver breaking change. Extending the owned version of a person name into a dedicated type (OwnedPersonName) would be feasible and have the benefit of being as efficient as it can be in the case where no additional ownership is necessary. Admittedly, it implies replicating more code, such as having two person builders.

• New structs OwnedPersonName and OwnedPersonBuilder, would use String for every field;
• One could trivially obtain a PersonName<'a> from an OwnedPersonName with a method call;
• Parsing a person name would still result in a borrowed PersonName, but would have a ToOwned implementation into a OwnedPersonName.

Let me know your thoughts on this.

Hello!

I believe we could introduce the variation you proposed if our primary goal here is to avoid any semver-breaking changes. However, the current approach in this PR has several characteristics that, in my view, may justify keeping it as is:

• As you stated, having a single PersonName struct that supports both use cases aligns better with the DRY principle, improving maintainability and making it easier to achieve higher test coverage.
• While PersonName is a useful struct for specific situations, it does not appear to be widely used in open-source code I could find. Moreover, the breaking changes introduced by this PR are relatively minor and easy to migrate to if needed, so developer churn should remain negligible.
• Though admittedly a niche use case, a single struct with Cows is the only way to support person names where some component strings are owned and others are borrowed. For example, a separate OwnedPersonName struct would not allow the following clone-free code, which this PR enables:

let mut name_builder = PersonName::builder();
name_builder.with_given("John"); // Borrowed from constant binary data
name_builder.with_family(String::from("Doe")); // Owned, may come from a buffer
let dicom_pn = name_builder.build().to_dicom_string(); // Doe^John

Ultimately, I'd understand if you decide this approach is not worth the technicality of being backwards incompatible, so please let me know how you'd like to proceed. For what it’s worth, in my experience as a library user, the PersonName implementation in this PR feels quite ergonomic, as it's easy and efficient to use whatever string variant comes from other parts of an application, and the additional generics usually don't need to be written or even deeply understood to be effective.

Fair enough, this can added to the 0.9 milestone.

Thanks for the reminder, @Enet4! I just wanted to quietly rebase this PR onto the latest master commits to keep it mergeable and not too distant from the mainline :)