Nuances influencing struct member visibility?

[sempervictus]

Thanks for getting this to build on stable releases - big win.
As i'm digging through using the library, i'm running into some odd visibility issue that i can't quite explain. When modifying the Message struct to expose fields,

#[derive(Debug, PartialEq)]
pub struct Message<'a> {
    pub source: &'a str,
    pub segments: Vec<Segment<'a>>,
}

and using the code from that file's test section in evcxr (with one minor change of ? to unwrap()), i'm getting private field errors on access attempts to the struct:

>> let hl7 = "MSH|^~\\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4\rOBR|segment";
>> let msg = Message::from_str(hl7).unwrap();
>> msg.segments
       ^^^^^^^^ private field
field `segments` of struct `Message` is private
>> msg.source
       ^^^^^^ private field
field `source` of struct `Message` is private

Debug prints show that the structure is populated correctly, but i'm unable to actually interact with the segments.
The segment structs have public members already, so i figure its not some implication derived by the compiler that a potential element may be private, unless its deeper in the stack than a GenericSegment.
@wokket: Any chance you might have some insights to what i'm doing wrong here?

[wokket]

Missing the public visibility segments is on me, as I've only actually used my own code from the tests (which can obviously access privates). Thanks for pointing that out for me.

Unfortunately I couldn't repro your issue directly.... I've exposed the fields directly for you, and confirmed (via an updated benchmark which I think should see the crate like external code) that I can access field data.

I've pushed 0.2.2 to crates with these changes anyway, if it still isn't working let me know and I'll dig deeper.

[sempervictus]

Thank you - verified working.