To clarify, is the following the use case you're interested in?

mutation Update {
    updatePerson(  ## this operation sets phone to null
        input: {
            id: ..., 
            name: ...,
            phone: null
        }
    ) {
        ...
    }
}

vs

mutation Update {
    updatePerson(  ## this operation does not modify phone number
        input: {
            id: ..., 
            name: ...
        }
    ) {
        ...
    }
}

yep

I think this is a solid proposal. Both Option and Maybe are valid choices, though Maybe seems to be slightly better maintained. However, I’m not entirely sure if this justifies adding a third-party library as a dependency.

For an opt-in approach, I would prefer your solution:

strawberry.register_option_type((MyOptionType, NOTHING))

If this Type is meant to be included directly in Strawberry, I would avoid forking the repository. Instead, I’d suggest copying the relevant MIT-licensed code while ensuring proper attribution, such as adding credits in the form of code comments or including a reference to the original license.

@patrick91 👀 ?

Code sample in pyright playground

from __future__ import annotations
import dataclasses
from typing import Self, reveal_type


@dataclasses.dataclass
class Some[T]:
    value: T
    
    def some(self) -> Self:
      return self
    
@dataclasses.dataclass
class Nothing[T]:
    def some(self) -> None:
      return None 

type Maybe[T] = Some[T | None] | Nothing[T]

def some_func() -> Maybe[str]:
    return Some("a")

a = some_func()

reveal_type(a)

if phone := a.some():
    reveal_type(phone)
    reveal_type(phone.value)
else:
    reveal_type(phone)

I have met the exact same problem, but I don't understand why you cannot solve it.

@strawberry.input
class UpdatePersonInput:
    id: strawberry.ID
    name: str| None
    phone: str | None | UnsetType = strawberry.field(
        graphql_type=str | None,
        default=UNSET
    )

@strawberry.mutation
def update_person(input: UpdatePersonInput) -> Person:
    inst = service.get_person(input.id)
    if name := input.name:
         inst.name = name
    if not instance(input.phone, UnsetType):
        inst.phone = phone.value
    
    service.save(inst)

The case where you do not want None but either a string or nothing cannot be handled cleanly due to the GraphQL specification (an optional value is a nullable value**), but if your API is used only internally, you can do the same thing:

@strawberry.input
class UpdatePersonInput:
    id: strawberry.ID
    name: str| None
    phone: str  | UnsetType = strawberry.field(
        graphql_type=str | None,
        default=UNSET
      description="This value is optional but not nullable, do not send a null!"
    )

(Arguably you could write custom code to ensure that sending a None would return an appropriate error instead of randomly breaking inside your code)

I find the proposition slightly contrived, as it turns scalar values into objects.

@Corentin-Bravo

phone: str | None | UnsetType

can actually solve this, I haven't thought about this really...

Though:

1. nothing stops you from using UNSET on anything.
   UNSET is UNSET: Any = UnsetType()
   because how we advertised the use of unset up until now which is

phone: str | None = strawberry.UNSET

You could say that we can change the signature to the real type but that would type-checkers would lint
for existing code and would require modifications.

2. using isinstance is not very pleasant to use IMO. (prob could avoid that with a typegaurd)

We could also think re-introducing the Unset usage which could look like this

type Maybe[T] = UnsetType | None | T

def is_unset[T](val: T | UnsetType) -> TypeGuard[UnsetType]:
    return isinstance(val, UnsetType)


@strawberry.input
class UpdatePersonInput:
    phone: Maybe[str]

def update_person(input_: UpdatePersonInput) -> ...:
       if not strawberry.is_unset(input_.phone)
           update_phone(input_.phone)  

I actually have no oppositions to this.