docs: clarify nullability explanations #850
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lorenarosati
requested review from
EpsilonPrime,
cpcloud,
jacques-n,
vbarua and
westonpace
as code owners
yongchul
previously approved these changes
Aug 8, 2025
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. The nullability of the expected return type in the function definition can be disregarded, as the nullability of the output is determined by the nullability of the inputs. An example might be the `+` function. | | ||
| | DECLARED_OUTPUT | Input arguments are accepted of any mix of nullability. The nullability of the output function is whatever the return type expression states. Example use might be the function `is_null()` where the output is always `boolean` independent of the nullability of the input. | | ||
| | DISCRETE | The input and arguments all define concrete nullability and can only be bound to the types that have those nullability. For example, if a type input is declared `i64?` and one has an `i64` literal, the `i64` literal must be specifically cast to `i64?` to allow the operation to bind. | | ||
| | DISCRETE | DISCRETE nullability follows DECLARED_OUTPUT rules, in the sense that the output nullability must match the return type expression's nullability. However, the input and arguments all define concrete nullability and can only be bound to the types that have those nullability. For example, if a type input is declared `i64?` and one has an `i64` literal, the `i64` literal must be specifically cast to `i64?` to allow the operation to bind. | |
There was a problem hiding this comment.
nit: follows DECLARED_OUTPUT rules -> follows DECLARED_OUTPUT rule
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. The nullability of the expected return type in the function definition can be disregarded, as the nullability of the output is determined by the nullability of the inputs. An example might be the `+` function. | | ||
| | DECLARED_OUTPUT | Input arguments are accepted of any mix of nullability. The nullability of the output function is whatever the return type expression states. Example use might be the function `is_null()` where the output is always `boolean` independent of the nullability of the input. | | ||
| | DISCRETE | The input and arguments all define concrete nullability and can only be bound to the types that have those nullability. For example, if a type input is declared `i64?` and one has an `i64` literal, the `i64` literal must be specifically cast to `i64?` to allow the operation to bind. | | ||
| | DISCRETE | DISCRETE nullability follows DECLARED_OUTPUT rules, in the sense that the output nullability must match the return type expression's nullability. However, the input and arguments all define concrete nullability and can only be bound to the types that have those nullability. For example, if a type input is declared `i64?` and one has an `i64` literal, the `i64` literal must be specifically cast to `i64?` to allow the operation to bind. | |
vbarua
reviewed
Aug 8, 2025
| | Mode | Description | | ||
| | --------------- | ------------------------------------------------------------ | | ||
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. An example might be the `+` function. | | ||
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. The nullability of the expected return type in the function definition can be disregarded, as the nullability of the output is determined by the nullability of the inputs. An example might be the `+` function. | |
There was a problem hiding this comment.
Beyond the scope of this PR, but I filed #853 to capture the fact that setting the nullability of the return type in these cases is meaningless.
| | Mode | Description | | ||
| | --------------- | ------------------------------------------------------------ | | ||
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. An example might be the `+` function. | | ||
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. The nullability of the expected return type in the function definition can be disregarded, as the nullability of the output is determined by the nullability of the inputs. An example might be the `+` function. | |
There was a problem hiding this comment.
suggestion:
An example might be the + function.
to
An example of a function with MIRROR nullability is the add function
With your addition, I read the example as an example of disregarding the nullability in the definition.
| | MIRROR | This means that the function has the behavior that if at least one of the input arguments are nullable, the return type is also nullable. If all arguments are non-nullable, the return type will be non-nullable. The nullability of the expected return type in the function definition can be disregarded, as the nullability of the output is determined by the nullability of the inputs. An example might be the `+` function. | | ||
| | DECLARED_OUTPUT | Input arguments are accepted of any mix of nullability. The nullability of the output function is whatever the return type expression states. Example use might be the function `is_null()` where the output is always `boolean` independent of the nullability of the input. | | ||
| | DISCRETE | The input and arguments all define concrete nullability and can only be bound to the types that have those nullability. For example, if a type input is declared `i64?` and one has an `i64` literal, the `i64` literal must be specifically cast to `i64?` to allow the operation to bind. | | ||
| | DISCRETE | DISCRETE nullability follows DECLARED_OUTPUT rules, in the sense that the output nullability must match the return type expression's nullability. However, the input and arguments all define concrete nullability and can only be bound to the types that have those nullability. For example, if a type input is declared `i64?` and one has an `i64` literal, the `i64` literal must be specifically cast to `i64?` to allow the operation to bind. | |
There was a problem hiding this comment.
suggestion:
DISCRETE nullability extends DECLARED_OUTPUT. The output nullability must still match the return type expression's nullability. Additionally, the
Effectively:
- Removing the
in the sensefor precision - Using
Additionallyinstead ofHoweveras the new constraints are additive and not instead of.
yongchul
approved these changes
Sep 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The explanations of the different nullability handling modes could be more clear.