using optional_field when autogenerating decoder

[amdRyzen5600X]

when generating decoder for a type, use optional_field by default for fields with option.Option(a) types
alternatively, add additional option for using optional_filed for that fields instead of regular field
example:
for that type

pub type Voice {
  Voice(
    file_id: String,
    file_unique_id: String,
    duration: Int,
    mime_type: Option(String),
    file_size: Option(Int),
  )
}

should be generated(or should be option to generate) this decoder

pub fn voice_decoder() -> decode.Decoder(Voice) {
  use file_id <- decode.field("file_id", decode.string)
  use file_unique_id <- decode.field("file_unique_id", decode.string)
  use duration <- decode.field("duration", decode.int)
  use mime_type <- decode.optional_field(
    "mime_type",
    option.None,
    decode.optional(decode.string),
  )
  use file_size <- decode.optional_field(
    "file_size",
    option.None,
    decode.optional(decode.int),
  )
  decode.success(Voice(
    file_id:,
    file_unique_id:,
    duration:,
    mime_type:,
    file_size:,
  ))
}

[lpil]

This change would mean that the decoder no longer matches the type definition. The decoder says the field can be absent and is nullable, but the type definition says it must be present but is nullable.

[amdRyzen5600X]

isn't nullable field implies that field can be absent?
for example in serde, if one of the fields are Option type, serde traits that field as nullable and may be absent by default

[GearsDatapacks]

As far as I remember, serde requires explicit specification of possibly missing values, using #[serde(default = None)] and #[serde::skip_serialization_if(Option::is_none)]

(Syntax may be slightly wrong)

[abs0luty]

This is serialization/encoding, we're having a discussion about generating deserializer/decoder for gleam types. And as @amdRyzen5600X pointed out, in serde optional fields imply field can be absent:

use serde::Deserialize;

#[derive(Debug, Deserialize)]
struct OptionA {
  value_1: Option<i32>,
  value_2: Option<String>,
}

fn main() {
    // Ok(OptionA { value_1: None, value_2: None })
    println!("{:?}", serde_json::from_str::<OptionA>("{}"));
}

[amdRyzen5600X]

As far as I remember, serde requires explicit specification of possibly missing values, using #[serde(default = None)] and #[serde::skip_serialization_if(Option::is_none)]

(Syntax may be slightly wrong)

i just checked, for the latest version of serde and serde_json, it traits fields of type Option as nullable and maybe absent, by default with no explicit specifications

[lpil]

isn't nullable field implies that field can be absent?

No, it's one that can be null.

[abs0luty]

Agree with @amdRyzen5600X.

Even if tools like Serde commonly treat missing fields as None during deserialization, and Gleam may want to keep a stricter distinction between None and absent, it'd be great to have an opt-in for codegen: generate decoders that use decode.optional_field for Option(...) so absent keys map to None as a distinct feature.

That would improve ergonomics for writing APIs that omit optional keys, like optional query parameters in http requests or configs. I’m happy to add this as an additional code action in #5078.

[lpil]

Unlike serde have full control over the decoders. You can write any code you desire.

The code action is faithful to the type definition, if you want otherwise then a different tool would be more appropriate.

[amdRyzen5600X]

it's actually frustrating to change to optional_field from field, especially in huge structs, it would be nice to choose between 2 types of decoder auto gen

also what "different tool" you're referring to?

[GearsDatapacks]

The thing is, this isn't the only time there are two plausible options for a decoder depending on the format of input. You might be decoding JSON that uses camelCase or kebab-case for field names and want the code action to rename those fields. If we wanted to support all of those options, we would need 6 different code actions which is not practical. For a more customisable approach, some external code gen tool which can receive some sort of configuration, would be more appropriate.
I am not aware of a feature-complete tool like that that exists at the moment, so someone would need to make it first

[lpil]

The language server protocol doesn't support any kind of functionality that would let us ask the programmer what encoding they would want for each field, so it is not an option today.

There is no single format that is universally desired, so we will remain consistent with the type definition.