Skip to content

Use case overlap between UNSET and MaybeΒ #4069

@DrumsnChocolate

Description

@DrumsnChocolate

Feature Request Type

  • Core functionality
  • Alteration (enhancement/optimization) of existing feature(s)
  • New behavior

Description

First of all, thanks a lot for this amazing library. We make great use of πŸ“ for several of our django projects. πŸ“ offers an abundance of features, and its extensibility is great.

problem statement

With that said, we have run into some confusing behaviour around the UNSET scalar and Maybe type. It is unclear to us what unique functionality UNSET provides that Maybe does not cover. We regularly make use of the Maybe type, but parsing input types is complicated by the existence of UNSET as one of πŸ“ 's fallback value for some types.

our thought process

There are three possible 'states' identified by the docs on Maybe: https://strawberry.rocks/docs/types/maybe#maybe

  1. Field present with a value
  2. Field present but explicitly null
  3. Field completely absent.

In other words, Maybe is aimed at enabling (but not forcing) differentation between nullable and optional.

Let's exhaustively list the possible types that we can construct since Maybe has been introduced:

field type provided value absent null
int 1 PROHIBITED PROHIBITED
int | None 1 None None
Maybe[int] Some(1) None PROHIBITED
Maybe[int | None] Some(1) None Some(None)

We can see here that absent and null are considered separate states in row 3 and 4, but this is not forced, since row 2 also exists. Nowhere in this table do we see a need for UNSET.

The docs for UNSET descibe it as:

A special value that can be used to represent an unset value in a field or argument. Similar to undefined in JavaScript, this value can be used to differentiate between a field that was not set and a field that was set to None or null .

This seems like it does not cover any use case that is not covered by Maybe.

In contrast, we do find that Maybe covers use cases that are not covered by UNSET, such as #2144

conclusion

Unless we are missing an important use case we did not mention above, we would request removal/deprecation of UNSET.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions