Positioned trait may be more static for performance reason.

[38]

pub trait Positioned {
    fn chrom(&self) -> &str;
    fn start(&self) -> u64;
    fn stop(&self) -> u64;

    // extract a value from the Positioned object Field
    fn value(&self, f: Field) -> Result<Value, FieldError>;
}

/// Value can be any number of Ints, Floats, or Strings.
pub enum Value {
    Ints(Vec<i64>),
    Floats(Vec<f64>),
    Strings(Vec<String>),
}

This Field type is a runtime polymorphism, which is not very desired for performance considerations. Actually you can make a faster version of the trait (and also more generic) with the following def.

pub trait Positioned<FieldType: Field> {
    fn chrom(&self) -> &str;
    fn start(&self) -> u64;
    fn stop(&self) -> u64;

    // extract a value from the Positioned object Field
    fn value(&self) -> Result<FieldType::Output, FieldError>;
}
trait Field {
    const NAME: &'static str;
    type Output;
}

And then you may have things like

struct Score;
impl Field For Score {
   const NAME: &'static str = "score";
   type Output = f64;
}

let score = Positioned::<Score>::value(&positioned);

[brentp]

Thanks Hao! I'm very glad to have your feedback! This is definitely at the bounds of my understanding.

With this setup, any Field would have to be known at compile time, right? I would like to support more dynamic field access as well.
How would this work with python bindings where I'd want the user to be able to choose arbitrary fields, like "INFO.AF" ?

I think that perhaps, the value method in the Positioned trait is not needed now that we have the Position enum. Instead of relying on value calls, we can instead discover the concrete type from the enum and then choose the appropriate means of getting information out.