visibility changed in recent commit

[brentp]

d743a34 made some previously pub attributes and functions pub (crate) or private.
I understand that encapsulation is good, but there is often a need to access the inner bcf_hdr_t, for example from the Header or HeaderView.

I'd like to have as pub:

• bcf::header::HeaderView::new()
• bcf::header::Header.inner

@jeeeesper @johanneskoester

[brentp]

here's one example why this is needed: #429

[jeeeesper]

I agree, especially since the library does not expose the feature set of htslib completely yet. I can create a PR when I get to it, maybe in a few days.

Similar reasoning e.g. for getting a raw pointer to the bcf record:

rust-htslib/src/bcf/record.rs

Lines 212 to 213 in d743a34

	/// Note that this function is only required as long as Rust-Htslib does not provide full
	/// access to all aspects of Htslib.

[jeeeesper]

What are we thinking about an approach like in #504? Using unsafe methods instead of making the field public. Happy to discuss on this as I'm also not sure if this is better compared to just making the field pub again. I feel like it would make the API a bit cleaner, since the caller must explicitly use unsafe when doing stuff with the raw pointer. On the other hand, the user will use unsafe anyways to call one of the C methods.

[brentp]

That is fine with me and the unsafe seems like a good marker to be wary even if it would require using unsafe in order to call any of the C methods.

[jeeeesper]

Can this be closed as #504 is merged and released? @johanneskoester