Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solution 5. passes criteria P. #1668

Closed
wants to merge 2 commits into from
Closed

Solution 5. passes criteria P. #1668

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
aaea7c7
Update SemanticNullability.md
martinbonnin Feb 21, 2025
c3cea58
Merge branch 'main' into martinbonnin-patch-2
benjie Mar 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions rfcs/SemanticNullability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -452,8 +452,8 @@ Criteria score: X (not considered - covered by B and G)
[criteria-p]: #-p-the-solution-should-result-in-users-marking-all-semantically-non-null-fields-as-such

When a field returns data that the business logic dictates does not and will
never return a legitimate (non-error) null, the schema authors should have no
hesitation over marking it as semantically non-nullable - and thus all
never return a legitimate (non-error) null, the schema authors should be encouraged
to mark it semantically non-nullable - and thus all
semantically non-nullable fields should be marked as such.

Per Benoit:
Expand All @@ -466,7 +466,7 @@ Per Benoit:

| [1][solution-1] | [2][solution-2] | [3][solution-3] | [4][solution-4] | [5][solution-5] |
|-----------------|-----------------|-----------------|-----------------|-----------------|
| ✅ | ✅ | ✅ | ✅ | 🚫 |
| ✅ | ✅ | ✅ | ✅ | ✅ |

Criteria score: 🥇

Expand Down Expand Up @@ -843,4 +843,4 @@ This proposal relies on the ability of clients to opt out of error propagation;
- [O][criteria-o]
- 🚫 Changing fields to strictly non-null causes errors to propagate further, a breaking change. (Duplicate of G.)
- [P][criteria-p]
- 🚫 Though the solution states it encourages the adoption of non-null, doing so is a breaking change for existing clients and so adopters are likely to hesitate when marking some semantically non-nullable positions as such
- ✅ The solution encourages using the existing syntax to express semantic non-nullability.