Part of the question is who should do the type conversion, and the other part is what should happen if the types in the file don’t match the expected types.

Ideally, I think a parser would come in two parts. A low level parser, and then an extensible set of type converters. The statically-type application would have structures with a fixed set of fields, so to read in any particular value it would fetch the node from the parser, and then use the type converters to marshal that node into application’s desired type. My simple example in the post — node.ConvertToFloat() — was definitely bad, because that level of declaration doesn’t allow for any extensibility; there’d be no way for the app to participate in the conversion when it needs to(!).

My actually sample parser has a simple two level setup but I didn’t reflect that into this post well.

It definitely would make sense for the converter layer to throw or return some sort of continuable error to make sure the application knows that something strange is going on any time the application asks for a type that doesn’t match the node type.

My sample parser doesn’t provide a good facility for that — the converter layer is too simple, and could probably use some work.