I agree with peer comment that we should likely defer to the original type for JSON serialization.

Where do you get this from? I've tried unsuccessfully to find such naming/design guidelines.

[1]: https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...

Pointers to pointers are generally something you try to avoid if possible.

But any benefits of the packing are gone whether I make a pointer or not.

And either way, no nested pointers are involved. We’re not taking pointers to options in either case.

to use a tired example: when getting a value out of a map via some `myMap.get(key)`, you may want to distinguish "not present" = `None` and "present, with value null" = `Some(null)`

the right solution is to just not have nulls in the first place, then there's no problem ;)

Some(null) is not a valid result.

The whole point of the Option type is to let you know:

a) we got a result: Some(value)

b) there is no result: None

  struct Foo;
  
  fn main() {
      let option_with_null: Option<*const Foo> = Some(std::ptr::null());
  
      dbg!(option_with_null);
      dbg!(option_with_null.is_none());
  }

  [src/main.rs:6] option_with_null = Some(
      0x0000000000000000,
  )
  [src/main.rs:7] option_with_null.is_none() = false

> Some(null) is not a valid result.

It is a valid result. Null pointer and Option::None are still different things, is all.

That means you must have Optional[*sync.Mutex]. Then what's the point?