this becoming complex. maybe ini should be shard.

also parse with regex super slow. what about scientific notation for float? maybe also parse time, like yaml?

best solution: everything is string, user can choose what to parse. ini has no standard.

so 👎

this becoming complex. maybe ini should be shard.

What's the process for breaking this out into a shard?

also parse with regex super slow. what about scientific notation for float? maybe also parse time, like yaml?

We're already using regexps to parse INI, so I didn't think this would add too much performance overhead. I agree, though: A real parser with parse time checks would be better. (That's something I can develop, if there's interest).

best solution: everything is string, user can choose what to parse. ini has no standard.

The fact that INI has no standard means we can be more rigorous, no? Type coercion is one of those things that should be gotten right once, so that users don't have to do it themselves (with various degrees of correctness/quality).

Overall, I'd like to see a feature like this (even if it was optional, like parse(str, coerce: true). If sharding INI is what it takes, let me know what I can do!

i mean, ini with types is a different shard. ini in std is simple and useful to everyone. want int? ini["section"]["value"].to_i. otherwise this breaks existing code. and to get int you need ini["section"]["value"].as(Int). even longer than now! and probably slower because of extra regex (to_i doesnt use regex)

ini in std is simple and useful to everyone.

I think it would be more useful with type guarantees. Like I said in #5441 (comment), though, this could be made optional.

otherwise this breaks existing code

Yes, but Crystal's development is currently in an alpha stage. From the README:

The project is in alpha stage: we are still tweaking the language and standard library.

and probably slower because of extra regex (to_i doesnt use regex)

I implemented this with regex because INI.parse uses it and it's simple. Of course, it doesn't have to use regular expressions at all.

Please no. INI format is not officially standardized but that doesn't mean you can do whatever you want. It should do what everyone else does. And that is, it contains KV pairs of strings. No other data types.

INI is simple and easy, don't make it complicated. Your implementation has no means to specify a string consisting of only digits. You'd need some escaping for that like quotes in YAML. That makes it way to complex and wouldn't work with other INI implementations.

A PR implementing a custom parser without regular expressions (but keeping the current behaviour) would certainly be welcome.

Your implementation has no means to specify a string consisting of only digits.

I hadn't thought about that!

A PR implementing a custom parser without regular expressions (but keeping the current behaviour) would certainly be welcome.

I'll focus on that.

Thanks for the reviews, @larubujo and @straight-shoota!