Discussion: Investigate Into or TryInto impl to convert our Segments into the strong typed Segments in [hl7](https://docs.rs/hl7/0.0.2/hl7/) crate

[sempervictus]

Querying into the MSH doesn't work well due to constraints around running iterators and ownership required to index into the fields - i tried a match pattern, its pretty gross.
What if we keep the MSH data structure as a GenericSegment but implement functional accessors to the well-known fields? Separators would move to the Message struct to be referenced or copied (its bytes) by its segments, and then every data element is consistent in both structure and impl. Thoughts?

[wokket]

What if we removed all the MSH specific stuff from the main library, but added an example of how to 'wrap' the library to produce a strongly typed segment in a consuming app? MSH would be a good example (as everyone uses it) and also helps confirm the API is workable from the outside.

Thoughts?

[sempervictus]

Thats kind of what i did in #31 - you can still call msg.msh().unwrap() to get a strongly-typed but non-iterable segment of fields over the original segment's string reference. I think this is the avenue toward "eating" the other library (presuming that author is ok with it) to have a bunch of strongly typed derivatives atop an efficient data/access layer with common iterator and search semantics over the generic sub-components.

[wokket]

I have no desire to impinge on the other library, given it provides lovely rich fully typed segments etc and I'm not going there. If the two libraries end up working together well that's awesome, but not currently on my radar.

[sempervictus]

Fair, though the idea in question isn't so much to impinge on theirs as to have an Into impl from the generic segments we have to their specific/typed segments or do it as we have msh() working in #34 (#31 really)

[wokket]

Gotcha, Into impl for that library sounds cool. I'd want it behind a feature gate to reduce dependency size but would be worth investigation at some stage.

[sempervictus]

Agreed. The feature mechanisms is a very nice way to expose additional functionality while keeping the core lib clean and minimally opinionated.