Improve decode.optional_field

[ghivert]

I'm currently rewriting my old decoders with the new gleam/dynamic/decode API, and I think it's time now to talk about areas of improvements, before the stdlib bumps to v1.0.0.

decode.optional_field

Usually, you can reasonably expect every optional function to return an Option(a). It's written in the name, and that's what you're looking for: indicate me in my code that the optional field has been handled, and returns an Option(a). This let the author handling the optional value.
But optional_field has a different opinion, and forces you to get a default value. So you have to provide a default value, and optional_field will automatically default to it if no field can be parsed. In case you want an Option(a), you have to write a really convoluted code:

use _ <- decode.optional_field("field", option.None, decode.optional(decode.string))

In addition that you have to handle the optionality by hand, this also prevents you to handle some specific cases. For example, that code is unable to make a difference between the two JSON { "field": null } & {}. In both cases, optional_field will feed the result with the default argument. But it's two different structures, and maybe you want to handle them differently. Maybe you want {} to succeed and { "field": null } to fail, because you expect field to always contains a value, or being non-existent at all.

I think optional_field should not return a default value. In case of error, returns the default value option.None, otherwise returns option.Some(a). Furthermore, if we consider that optional_field should be rewritten without default value, handling unwrapping of Option(a) is really straightforward with gleam/option.unwrap:

decode.optional_field("field", decode.string)
|> decode.map(option.unwrap(_, ""))

Even in case we want to handle a potential optional field that could be optional itself, it's a matter of writing:

decode.optional_field("field", decode.optional(decode.string))
|> decode.map(option.flatten)

But at least, you're free to manipulate the dynamic data as you want, we fine granularity.

[lpil]

Usually, you can reasonably expect every optional function to return an Option(a)

This is not the case- there are many other defaults you want to use, and I would suggest that often None is not the best one.