starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #1865] "into_<fields>" methods #798

New issue

Open

opened 2026-03-16 00:17:13 +03:00 by kerem · 7 comments

kerem commented

2026-03-16 00:17:13 +03:00

Owner

Originally created by @mattfbacon on GitHub (Dec 21, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1865

Consider this struct: https://docs.rs/trust-dns-proto/0.22.0/trust_dns_proto/rr/rdata/mx/struct.MX.html

It has an owned Name field, but there is no way to get that out of it; you can only get &Name.

For efficiency purposes, I would like to be able to do into_exchange to get Name from MX.

This applies in general to all similar data types.

Originally created by @mattfbacon on GitHub (Dec 21, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1865 Consider this struct: https://docs.rs/trust-dns-proto/0.22.0/trust_dns_proto/rr/rdata/mx/struct.MX.html It has an owned Name field, but there is no way to get that out of it; you can only get &Name. For efficiency purposes, I would like to be able to do `into_exchange` to get Name from MX. This applies in general to all similar data types.

kerem added the

perf

label

2026-03-16 00:17:13 +03:00

kerem commented

2026-03-16 00:17:24 +03:00

Author

Owner

@djc commented on GitHub (Dec 22, 2022):

Do you actually have a benchmark where this matters?

In general, pull requests for stuff like this are welcome! For this particular type, I wonder if we should just make the fields public instead...

@djc commented on GitHub (Dec 22, 2022): Do you actually have a benchmark where this matters? In general, pull requests for stuff like this are welcome! For this particular type, I wonder if we should just make the fields public instead...

kerem commented

2026-03-16 00:17:29 +03:00

Author

Owner

@mattfbacon commented on GitHub (Dec 22, 2022):

I agree that making the fields public would be the best option if possible. I thought they were private for backwards-compatibility or something.

I don't think it makes a huge performance difference. It's just annoying to have to Clone when I would be able to take out the field.

@mattfbacon commented on GitHub (Dec 22, 2022): I agree that making the fields public would be the best option if possible. I thought they were private for backwards-compatibility or something. I don't think it makes a huge performance difference. It's just annoying to have to Clone when I would be able to take out the field.

kerem commented

2026-03-16 00:17:34 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 22, 2022):

Generally, I like keeping internal fields private, like you said @mattfbacon, for backward compatibility concerns. That being said, the RecordData types probably won't change, so maybe it's not a concern there?

@bluejekyll commented on GitHub (Dec 22, 2022): Generally, I like keeping internal fields private, like you said @mattfbacon, for backward compatibility concerns. That being said, the RecordData types probably won't change, so maybe it's not a concern there?

kerem commented

2026-03-16 00:17:39 +03:00

Author

Owner

@mattfbacon commented on GitHub (Dec 22, 2022):

OK if making the fields public is acceptable then I will make a PR doing that soon.

@mattfbacon commented on GitHub (Dec 22, 2022): OK if making the fields public is acceptable then I will make a PR doing that soon.

kerem commented

2026-03-16 00:17:44 +03:00

Author

Owner

@djc commented on GitHub (Dec 27, 2022):

Yeah, for RecordData fields I think making the fields public is probably reasonable.

@djc commented on GitHub (Dec 27, 2022): Yeah, for `RecordData` fields I think making the fields public is probably reasonable.

kerem commented

2026-03-16 00:17:49 +03:00

Author

Owner

@mattfbacon commented on GitHub (Dec 30, 2022):

Were these structs generated automatically somehow?

@mattfbacon commented on GitHub (Dec 30, 2022): Were these structs generated automatically somehow?

kerem commented

2026-03-16 00:17:55 +03:00

Author

Owner

@djc commented on GitHub (Dec 30, 2022):