[fontdrasil] panic in `Location<Space>.convert`

[simoncozens]

This may come down to a philosophical difference: I don't think library code should panic and bring down the application when you call it with the wrong inputs, so I tend to avoid unwrap() (with unwrap_used = "deny") unless I've checked some invariants.

Location.convert does this:

    pub fn convert<ToSpace>(&self, axes: &Axes) -> Location<ToSpace>
    where
        Space: ConvertSpace<ToSpace>,
    {
        self.0
            .iter()
            .map(|(tag, coord)| (*tag, coord.convert(&axes.get(tag).unwrap().converter)))
            .collect()
    }
}

If the tag in the location is not present in the axes, I believe it should be skipped, or an Err raised, but the program should not explode.

[rsheeter]

I don't think library code should panic and bring down the application when you call it with the wrong inputs

Vigorously agree, this sort of thing results in queries of death instead of failing requests.

I suspect this code moved from somewhere that only called it with invariants checked to somewhere more accessible and we missed updating it.

[cmyr]

I'm going to split hairs here: library code is 100% allowed to panic (two quick examples) but public API that can panic based on the inputs should always clearly document the conditions under which a panic can occur, in a # Panic section of its docs.

[rsheeter]

Our library code should bias strongly away from panic. I'm sure there are cases where it's the right choice but it shoudl be extremely rare. It's a very very bad user experience for the server to go down instead of an API returning an error. Saying "it's documented" is not an adequate solution.