error on list where number types have different formatting
Closed this issue · 2 comments
this yaml file:
works: [0, 1]
broken: [0, 1.0]
produces this error:
error: InvalidCharacter
.../zig/zig-macos-aarch64-0.10.0-dev.3981+60678f5ba/lib/std/fmt.zig:1900:17: 0x104f09a77 in charToDigit (yaml)
else => return error.InvalidCharacter,
^
.../zig/zig-macos-aarch64-0.10.0-dev.3981+60678f5ba/lib/std/fmt.zig:1827:23: 0x104eee54f in parseWithSign__anon_8009 (yaml)
const digit = try charToDigit(c, buf_radix);
^
.../zig/zig-macos-aarch64-0.10.0-dev.3981+60678f5ba/lib/std/fmt.zig:1726:5: 0x104eb85a3 in parseInt__anon_5496 (yaml)
return parseWithSign(T, buf, radix, .Pos);
^
/private/var/tmp/zig-yaml/src/yaml.zig:198:43: 0x104eacaff in fromNode (yaml)
.int => Value{ .int = try std.fmt.parseInt(i64, raw, 10) },
^
/private/var/tmp/zig-yaml/src/yaml.zig:187:35: 0x104eac85f in fromNode (yaml)
const value = try Value.fromNode(arena, tree, elem, hint);
^
/private/var/tmp/zig-yaml/src/yaml.zig:163:21: 0x104eac457 in fromNode (yaml)
try Value.fromNode(arena, tree, value, null)
^
/private/var/tmp/zig-yaml/src/yaml.zig:155:13: 0x104eac1db in fromNode (yaml)
return Value.fromNode(arena, tree, inner, null);
^
/private/var/tmp/zig-yaml/src/yaml.zig:256:27: 0x104eabc0b in load (yaml)
const value = try Value.fromNode(arena.allocator(), &tree, node, null);
^
/private/var/tmp/zig-yaml/examples/yaml.zig:38:22: 0x104eaece7 in main (yaml)
var parsed = try yaml.Yaml.load(allocator, source);
What I expected was that all the numbers would be promoted to floats. I get why it doesn't work, just thought I would flag it.
Hi @ssteinbach, thank you so much for submitting the issue! I completely agree with you that mixing types in YAML lists should be legal and this is indeed a bug at least as far as generating a YAML Value
goes. When it comes to deserialising into Zig native types however, whether we should automatically promote an int into a float is debatable. Having said that though I believe that offering this basic type cast automatically will be strictly better than not having it as it seems to me like a pretty common thing to do and expect in YAML, and so I am in favour of letting this work as you would expect it. In the future, if there ever is any need for stricter typing, we can add an option to the deserialiser to not do this automatically.
Thanks!