search

kinnison / marked-data

A YAML representation library which explicitly retains provenance data
MIT License
13 stars 6 forks source link

Optional markers are awkward to use #19

Open not-my-profile opened 1 month ago

not-my-profile commented 1 month ago

marked-yaml currently uses the following type for spans:

pub struct Span {
    start: Option<Marker>,
    end: Option<Marker>,
}

Span::new_blank() says:

Sometimes we simply do not know where information came from (for example if it was created by software) and in that case we can create a blank span.

In my use case I'm however only ever using marked-yaml to parse YAML provided from the user, so the spans can always be known, yet the API currently forces me to litter my code with .unwrap(), which is rather awkward. I think a much more elegant way of modelling software-generated nodes would be to simply use a different source index for their markers.

kinnison commented 3 weeks ago

Having recently worked on something with spans where I knew it would have marks, I agree that this isn't particularly pleasant. Perhaps we could reserve usize::MAX for the synthetic "unknown" marks. Do you fancy prototyping a branch to do this?