Lee's new nullability & error propagation proposal

[leebyron]

I keep thinking... what is the end state that we want? I don't think we want 3 types representing forms of nullability, we just want 2: is it nullable or is it not?

From here we have two key questions:

1. What is the default unadorned type? Do we add a qualifier that a type is nullable? or that a type is non-nullable?

2. How do we introduce this in a non-breaking way? How would existing systems adopt this?

1. The default unadorned type should be semantically nullable

I've changed my mind from my earlier proposals. I believe the unadorned type should be nullable and the qualifier makes it non-null. Why? Pragmatically, because that's how GraphQL works today. Principally because in queryable data systems like GraphQL output types should become more constrained with more adornment (precedent: SQL's NON NULL operator). This is because as you evolve your schema, changing Int to Int? would be a breaking change where Int to Int! is not breaking.

One of the very early reasons why I preferred the other way around was an aesthetic one. I believe most systems will have more non-null fields than nullable. It bothers me that schema will be littered with !. I felt particularly strongly about this when we were focused on the "client-controlled" aspects of nullability and ! would appear all over queries. I've made my peace with this in schema, and I believe we have a path which does not disrupt queries.

2. We introduce this with a variant of Martin's "no error bubbling" proposal.

There are two types:

• Unadorned type is Semantically Nullable
• Adorned NonNull(T) / T! is Semantically Non-nullable.

There is no third "Strictly non-nullable" type. There is no error bubbling (by default).

Error bubbling becomes an opt-in legacy field level error handling behavior via propagateError introspection field described in detail below.

What is the desired end state?

Error bubbling is exclusively the domain of the client, and no longer occurs on the server. Optionally, we reintroduce a separate following client-controlled proposal for adding ! on query fields to opt-in to error bubbling in specific areas.

Anyone setting up a brand new GraphQL service should never need to know about error bubbling or strict non-null. There is no additional configuration, schema definition, or query qualifiers to add. There is no "strict mode" directive.

What does a new service with modern clients need to do?

Nothing.

They get semantic nullable and semantic non-nullable types by default! They're already in our desired end state.

What about existing clients?

There are three mechanisms for migrating to this desired end state, one for each of schema, service and request.

At a high level:

• Schema: A new @propagateError directive which opts-in to error bubbling (fka strict null). This is exposed via introspection.
  • New introspection field on Field — propagateError: Boolean
• Service: A propagateErrorOnAllNonNullFields which has the effect of auto-applying @propagateError to every non-null field.
  • This is optional, and plausibly not part of the spec. It's a convienience tool for migration.
• Request: A noPropagateError request level argument (sibling to, not part of, the operation document) which disables error bubbling on the server.

Let's look at it over the course of a migration timeline.

1. Opt-in to legacy behavior across the service

You update to a major version bump of GraphQL runtime (like GraphQL.js) which has in its release notes that the new default behavior is to not propagate errors. There is a config flag you can set called propagateErrorOnAllNonNullFields which you can provide : true - now all Non-null types will have exactly the legacy error bubbling behavior as they did before.

2. Update your in-development clients to be aware of propagateError and noPropagateError

This ensures new client development generates correct types and error management logic for all permutations of NonNull & propagateError. At this point, clients continue to behave as they did before, but are now resilient to future changes in schema which have NonNull types that do not also have propagateError.

Clients should also ideally provide noPropagateError at this step. This opts clients into a mode where errors never propagate, which gives them more local control over error handling.

3. Code-mod your schema to add @propagateError

After step 1, your service continued to operate as it did before, however you could not add new semantic non-null types yet without incurring more error bubbling, which we'd like to avoid.

There is a new well-known directive called @propagateError, which if applied to a field tells the GraphQL runtime to use the legacy error bubbling behavior. Update your schema such that every non-null typed field changes from field: Type! to field: Type! @propagateError.

Once you've done this, you can remove the propagateErrorOnAllNonNullFields service-wide config flag, since this is exactly what that flag did internally.

You can now also add new Non-Null typed fields without @propagateError. Because they are new fields, they are non-breaking to existing clients.

4. Remove @propagateError after all clients upgrade [Optional]

If you're lucky enough to sunset existing clients, then once all active clients provide noPropagateError, then you can remove all instances of @propagateError from your schema without any observable effect.

Once you've done this, clients can also remove their use of noPropagateError

Congrats! Now your GraphQL service and clients are fully in the modern era of semantic non-null without error bubbling.

What about third-party clients?

I admit that this proposal is quite biased towards first-party GraphQL installs. However that is the vast majority of the GraphQL userbase. The above migration path doesn't work well if you don't control all the clients, because you cannot get past step-2.

However public-facing APIs are well aware of this problem and their own mechanisms for managing API changes.

A hand-wavy proposal is to automatically set propagateErrorOnAllNonNullFields to true when recieving a request from an existing client which has not indicated that it's made this migration yet.

Criteria

https://github.com/graphql/graphql-wg/blob/main/rfcs/SemanticNullability.md#-solution-criteria

A. GraphQL should be able to indicate which nullable fields should become non-nullable when error propagation is disabled

✅ semantically non-null without propagateError

B. Existing executable documents should retain validity and meaning

~✅ See migration guide above. This is true when existing services must ensure propagateError is set when adopting this behavior.

C. Unadorned type should mean nullable

✅

D. Syntax should be obvious to programmers

✅ No new symbols. No new types. Error bubbling was previously implicit behavior, now it is explicit

E. Syntax used in SDL and in executable documents should be consistent with SDL

✅ No change to input types

F. Alternative syntaxes should not cause confusion

✅ (Is this a repeat of D?)

G. Error propagation boundaries should not change in existing executable documents

✅ (Is this a repeat of B?)

H. Implementation and spec simplicity

~✅ One new directive/introspection field. Behavior change is straightforward. Managing adoption/migration requires careful consideration.

I. Syntax used in executable documents should be unchanged

✅ This proposes no change to executable documents

J. Type reasoning should remain local

✅ The propagateError introspection/directive is local to the field (the optional propagateErrorOnAllNonNullFields config just does this for you)

K. Introspection must be backwards compatible

✅ Adds one new field. Migration path supports existing semantics for shipped clients.

L. General GraphQL consumers should only need to think about nullable vs non-nullable

✅ There are only two types and they remain the same as they are today. This proposal is about changing error bubbling behavior, not nullability.

M. The SDL should have exactly one form used by all producers and consumers

✅ First party APIs have a clear path to introduce propagateError for all consumers.
⚠️ Third party APIs have a more challenging migration path, and may wish to expose different Schema to different clients.

N. The solution should add value even with error propagation enabled

✅ Separating nullability from error bubbling allows for more control. Clients should preferably disable error bubbling, but even if they do not - this unlocks the ability for a semantically non-null type which does not error propagate.

O. Should not have breaking changes for existing executable documents

✅ (Is this a repeat of B?)

Note that once this behavior is adopted, removing propagateError for an existing field is a breaking change. However newly added fields can be semantically non-null without propagateError and existing documents will be unaffected.

P. The solution should result in users marking all semantically non-null fields as such

✅ This is technically not breaking, however note that changing field: Type to field: Type! does introduce a new source of errors (which may be preferable!) Doing this without adding @propagateError is preferred, since changing field: Type to field: Type! @propagateError, could lose data - and is exactly why this kind change is discouraged today.

Q. Migrating the unadorned output type to other forms of nullability should be non-breaking

✅ See C. and P.

R. Semantic nullability should only impact outputs, not inputs

✅ No proposed change to inputs

[leebyron]

Example migration

type Person {
  id: ID!
  name: String
  age: Int
  picture: Url
}

becomes:

 type Person {
-  id: ID!
+  id: ID! @propagateError
   name: String
   age: Int
   picture: Url
 }

after which you can add fields and constrain types without adding new error propagation sources:

 type Person {
   id: ID! @propagateError
-  name: String
+  name: String!
   age: Int
   picture: Url
+  email: String! 
 }

[leebyron]

Other Qs:

How does a client know to interpret a NonNull type in introspection as the old style always propagates vs the new style only if propagateError is set?

Annoyingly the same way we've done this for other changes to introspection. Introspecting clients need to query a new propagateError field of the Field type. Services that don't provide this field in introspection have the old behavior. Services that do provide this field in introspection require you to check it (and migration will start by having it always true to not create changes in behavior)

What about nested types like [Int!]!

Yeah, this is a degenerate case where we will not provide fine-grained control.

If the field provides propagateError then both inner and outer ! will propagate. If not, then neither will propagate. There is no way to suggest only one of them propagates and the other does not.

I think this reduction in ability is probably a good thing.

[leebyron]

Very very rough spec language changes:

On non-null type:

https://spec.graphql.org/draft/#sec-Non-Null

No changes! The behavior today is the correct one. Result coercion converts a null value to a raised error.

On field errors:

https://spec.graphql.org/draft/#sec-Handling-Field-Errors

This is the key language

Since Non-Null type fields cannot be null, field errors are propagated to be handled by the parent field. If the parent field may be null then it resolves to null, otherwise if it is a Non-Null type, the field error is further propagated to its parent field.

Similar to @martinbonnin prev proposal, the primary spec change is to qualify this by first looking at the field property if errors should propagate or not.

We'll need a note describing that prior versions of the spec did not require providing this and that services which do not should propagate IIF their field type was non-nullable.

(Side note - I see we use propagate instead of bubble in the spec today - obviously we should name these concepts in one way, not sure which word is best) Updated all references!

If a List type wraps a Non-Null type, and one of the elements of that list resolves to null, then the entire list must resolve to null. If the List type is also wrapped in a Non-Null, the field error continues to propagate upwards.

We will also need to address this

[leebyron]

cc @benjie @twof @martinbonnin

[martinbonnin]

In a way, @bubbleError is the symmetric directive of @semanticNonNull. Instead of having @semanticNonNull for the many years to come, use @bubbleError for the transition. Gives a clear path forward and doesn't change the syntax, I like it!

As you noted, we sometimes use "bubble" and sometimes "propagate". Personnal preference for @propagateError as it's the current spec language and also what we have been using for @disableErrorPropagation. See graphql/graphql-js#4348 (comment) for a discussion on the matter.

This proposal would require that we move from @disableErrorPropagation to a request parameter, which is the direction we were taking so lgtm 👍 (see graphql/graphql-js#4348 (comment) and graphql/nullability-wg#86)

[leebyron]

Lets do propagate - I'll update my proposal text

[leebyron]

In a way, @bubbleError is the symmetric directive of @semanticNonNull

that's exactly right! and yes the idea is to eat more pain during the transition in exchange for avoiding a permanent addition of syntax

[benjie]

Instead of having @semanticNonNull for the many years to come, use @bubbleError for the transition.

To be clear, @semanticNonNull only exists during the transition too, it's only needed if you want to narrow types for error-handling clients whilst legacy clients exist; once there are no more legacy clients, all @semanticNonNull types can be replaced with ! either all at once via tooling like semantic-to-strict, or gradually on a field-by-field basis. (Further: new fields do not need to use @semanticNonNull since they have no legacy to support - they can just use ! directly to start with.)

[martinbonnin]

I didn't get that initially, I think we weren't focused on using ! directly in the early @semanticNonNull days but that makes a lot of sense 👍 I'm all for transitional types!

[benjie]

I really like that we all seem to agree on the end state of where we're heading to!

I wonder if you could speak to how you feel this is superior to solution 6 (the @semanticNonNull directive which many engines have already adopted). Here's there comparison as I see them:

The similarities

Both @semanticNonNull and @propagateError see an end state in which they are not used:

• ✔️ no null bubbling
• ✔️ ! simply means "non-null", and doesn't factor in "errorability" - should be used to represent any semantically non-nullable position
• ✔️ no syntax changes or extra directives in SDL for new schemas (just use !)
• ✔️ no syntax changes or extra directives in SDL for new fields in existing schemas (just use !)
• ✔️ no new wrapper type in code-first for new schemas or new fields in existing schemas (just use GraphQLNonNull() or equivalent)
• ✔️ no change whatsoever in executable documents

Note

The aim for the @semanticNonNull directive is for the distinction between "semantic non-null" and simply "non-null" to go away. The distinction goes away when null bubbling is disabled. This is why I recently proposed that instead of calling it "semantic" non-null, we call it "transitive" non-null. But that's by-the-bye.

Both are only relevant when you need to support non-error-handling clients.

Both propose that all clients should be error-handling clients.

Both are only relevant to existing schemas (by extension of the above) and in fact only to existing fields in existing schemas (new fields have no legacy to support).

So when comparing them, we only need think about their impact on existing fields on existing schemas with deployed non-error-handling clients that need supporting.

Both need to support list elements

Thus their signatures are effectively equivalent:

• directive @semanticNonNull(levels: [Int!]! = [0]) on FIELD_DEFINITION
• directive @propagateError(levels: [Int!]! = [0]) on FIELD_DEFINITION

Note

The need to support list elements

Handling errors inside of lists is important (as confirmed at the nullability meeting just now).

An existing list type such as [Message] allows individual messages to fail to load - if we never want to represent a true null in this list this would want to migrate to [Message!]! under @propagateError, i.e. it's a list (unless a major error happened) and each entry in the list is a message (or an error). We can imagine an infinite scroll list where some of the entries are errors. It does not want to propagate errors.

Similarly a type like [User!] which acts as an error boundary but guarantees no single entry inside the list is non-null or error would want to to migrate to [User!]! @propagateError(level: [1])

And of course a type like [Int!]! wants to migrate to [Int!]! @propagateError(level: [0, 1])

Both of them require representation in introspection for tooling to know about them.

Both of them, IMO, represent a new type or type variant

In my opinion, both are actually a new type or type variant masquerading as a directive (much like the @oneOf input type). As seen above, they actually have levels within lists that they apply to - I put it to you that they are either a new type (SEMANTIC_NON_NULL and PROPAGATING_NON_NULL respectively) or a type variant of the existing NON_NULL.

Note

If we think about the handleFieldError method in GraphQL.js, the key place impacted by this, handling them as types would be much more straightforward than passing additional field metadata down.

(And keep in mind, this method is not just used for fields, it's also called from completeListValue when handling list items.)

But this is a separate discussion. Either way, both share whatever the conclusion is.

Both have a mechanism to disable error propagation

(And both, long term, want this mechanism to be enabled by default.)

Currently for @semanticNonNull it's proposed to be a request parameter (in the GraphQL Spec sense, not necessarily the HTTP sense) for which the server may choose (and indicate) the default. I think this is the same for @propagateError (though the actual field name proposed differs).

Both of them can be simplified down into two derivative schemas using only traditional syntax: one for legacy clients, and one for error-handling clients.

• @semanticNonNull can be stripped for legacy clients, and upgraded to ! for error-handling clients
• @propagateError can be stripped for error-handling clients, and ! downgraded to unadorned for legacy clients unless @propagateError is present.

The differences

Now we've seen how similar they are, let's focus on the differences (in no particular order).

Difference 1: @semanticNonNull is backwards compatible for introspection, @propagateError is not.

• Any schema can adopt @semanticNonNull today without impacting any existing clients or tooling whether or not they do introspection. There's no need for hesitation. Tooling performing introspection must opt-in to see the @semanticNonNull fields (otherwise they're treated as nullable in the traditional sense - i.e. error boundaries - which is safe for existing clients).
  • New tooling: adds semanticNonNullLevels to its __Field selection set. ¹
  • Existing tooling: unchanged, unimpacted, still generates correct (but more nullable) code.
• With @propagateError, from the moment that you update to the latest version, both clients and tooling need to be taught that a field marked as NON_NULL in introspection can have null data now.
  • New tooling: adds propagateErrorLevels to its __Field selection set.
  • Existing tooling: 🚨 incorrectly sees positions that can be null on error as if they will never be null. Generates incorrect types. DOES NOT KNOW THAT IT'S DOING THE WRONG THING. Breakage. ²

Note

I do not subscribe to the belief that GraphQL applications should not/do not perform introspection at runtime.

I don't think we state that applications shouldn't do runtime introspection in the spec or in any of our documentation? We provide the handy Query.__type field so you can enter introspection at a particular type and don't have to introspect the whole thing, which is very handy for runtime. If anything, I would like to expand GraphQL's runtime introspection capabilities (e.g. more convenient access points).

I've come across quite a number of end-user applications which in fact do do runtime introspection, one common use case for it is when populating dropdowns with options (e.g. for sorting) but I've also seen more complex cases. A particularly powerful example is react-admin though I'm sure there are many others: form builders, report generators, etc.

I've also worked with a number of clients that deploy GraphiQL for team members (particularly data analysts, it seems!) to use to query data; a break in introspection would require all versions of GraphiQL to be upgraded.

Difference 2: @semanticNonNull can be released in a minor version.

• @semanticNonNull will not break existing apps on upgrade, users don't need to know to turn on a particular setting for existing schemas. We can put it out in a GraphQL.js minor.
• @propagateError requires existing schemas to know to enable the propagateErrorOnAllNonNullFields option.

Difference 3: @propagateError is sort of misleading, @semanticNonNull is not.

• If you disable error bubbling, then @propagateError... doesn't actually propagate the error?
• @semanticNonNull indicates places that are semantically non-null whether or not error bubbling is disabled. When error bubbling is disabled, "semantic non null" and "non null" are the same thing.

Difference 4: @semanticNonNull maintains existing meanings and adds extra information through directives; @propagateError changes existing meanings and restores previous meanings through directives.

• "Additive changes: good" has generally been the GraphQL ethos.
• If a client is using @local schema extensions, when the schema suddenly enables @propagateError, the meaning of the clients local schema extensions may change? If so, the client would also need to know it needs to migrate its documents to using the directive on top of the schema having done so.

Difference 5: @semanticNonNull can be enabled and felt immediately and migrated to on a per-field basis sans tooling; @propagateError requires a code mod before its full benefits can be felt.

• Federation may have a hard time performing the @propagateError migration, since they likely have schemas implemented in many different languages.
• Schemas formed from multiple sources (especially where some are external or specified in different formats - e.g. a mixture of code-first and SDL-first) may have a hard time migrating to @propagateError since they will require multiple types of tooling.
• @semanticNonNull is purely additive; very easy to migrate to and can be added granularly with every single change having an immediate positive impact on error-handling clients (whether or not they disable error propagation).

Difference 6: APIs with third party clients can adopt @semanticNonNull without needing a version change; as you state, this is not the case for @propagateError.

---

It's late now and I'm afraid the only differences I could come up with seem to favour @semanticNonNull over @propagateError; if I've missed some that weigh the other way, I would love to have the gaps in my thinking pointed out!

Footnotes

1. If we agree this is actually a type, not a field property, then we'd actually add includeSemanticNonNull: true as an argument to the __Field.type field in this selection set instead. Either way, the change is similarly minimal. ↩

2. I know you laid out how to migrate to this in a non-breaking way, but that's simply not necessary with @semanticNonNull - it's non-breaking out of the box. ↩

[leebyron]

Thanks for this deep dive critique! I'm going to dig in more. I think we're definitely narrowing in on the sweet spot.

One thing I would like to do is create a clear separation between the concepts of nullability and error handling. Part of why I'm excited about this proposal is that it makes it very clear that what we're doing here is managing a major change to error handling - and not actually changing the type system in any way. This was a big realization to me that helped this feel much more manageable.

Perhaps there's an exploration of @semanticNonNull which just borrows this terminology?

It seems like amongst the differences you list (and I will read them much more carefully) the most important difference is the "symmetry" that @martinbonnin pointed out. Perhaps this is just @noPropogateError?

[leebyron]

I'd also like to dig in more on the "levels" concept. It's clever but I'm curious if we can forgo it entirely.

Especially if the goal is to have this be a tool for migrating from old to new, do we really need to migrate one level of type at a time within a field?

I didn't understand the example you provided. Could you help elaborate the case where providing partial levels is important (assuming the alternative is that this behavior applies to all levels in a type)

[benjie]

One thing I would like to do is create a clear separation between the concepts of nullability and error handling.

I think we're all agreed on this - when null bubbling is disabled, schema designers don't need to consider errors when thinking about nullability. They only need to consider it when designing for clients that do not disable null bubbling (and supporting existing such clients).

With @semanticNonNull I try and reflect this by focussing on the data (which we want people to think about) rather than the errors (which we don't!). You simply go through each of your existing nullable fields in your schema (and take as long as you like / hit the key ones that are causing the clients pain first) and you say to yourself: "is null ever a valid value for this field?" If the answer is no, you mark it @semanticNonNull, since that accurately describes the data. Once you shift over to only these future "error handling" clients, you can simply turn all @semanticNonNull into ! to tidy up.

Note: For new fields, you just use ! from the start, since they have no legacy to support - @semanticNonNull is only to allow transitioning legacy fields for error handling clients without breaking legacy clients.

I didn't understand the example you provided. Could you help elaborate the case where providing partial levels is important (assuming the alternative is that this behavior applies to all levels in a type)

Sure! Here's some examples from GitHub's API, Braintree's API and Monday.com's API. I've excluded [T] and [T!]! because I think we already agree these are important:

• [T]!
  • GitHub's Query.licenses: [License]! or License.conditions: [LicenseRule]!
  • Monday.com's Board.owners: [User]!
• [T!]
  • GitHub's Discussion.reactionGroups: [ReactionGroup!] or GitHubMetadata.gitIpAddresses: [String!]
  • Braintree's CreditCardConfiguration.supportedCardBrands: [CreditCardBrandCode!]
    • (Braintree's lists are always nullable in output positions)
  • Monday.com's Board.team_owners: [Team!]

[T]! guarantees a list, but allows the inside of the list to act as an error boundary - we'll definitely give you a list of these, but some of them might end up being errors. Here's an excerpt from a list where the developers have just added a rushed XSRF protection on the server side by refusing to render titles that contain the < character:

I know Facebook have mentioned they'd just filter these out (no nulls in lists), but often the fact data is missing may be important for context - imagine an address book app that no longer seems to contain your friend Teal'c. "Where is he?! I didn't delete him!" Actually his entry just errored due to some over-zealous validation, so we'd rather see an error in his place than nothing, right?

[T!] is kind of the reverse; in it we're guaranteeing the entries in the list exist, but we're allowing for failure to retrieve the list. This is common on service boundaries: I'm reading a list of Team from a database table on a separate service, I know no entry will be null or error because I can't have null rows in my database and I either fetch all of them or none of them... But actually fetching them might fail (e.g. the separate service is down).

---

I tend to see [T!] used a lot more than [T]!, and in general I think [T!] is a better type than [T] or [T!]! for legacy (null bubbling) schemas when it represents a service boundary - it removes painful list-item null checking for clients whilst still allowing for a service boundary failure without killing the query.

Legacy clients need these existing types to still be reproducible, if they become nullable then clients can NPE due to the expansion of the possible types in those places. If they become non-nullable then errors are no longer handled locally, and instead you might end up with a full page error as in this list of rendered widgets:

⇒

[martinbonnin]

I understand the desire to frame semantic nullability as an "error propagation only change". But I agree with @benjie that during the transition, there's probably no escape from proper types (transitional types). This is how it really works under the hood.

We could change the terminology to use @nullOnError or @noErrorPropagation but there is already some brain muscle around @semanticNonNull, there are a bunch of tools using it already and, if anything, this adoption proves the concept is viable.

For the "new" schemas and "new" users, this is really an "error propagation only change". Just turn on disableErrorPropagation. The types are only transitional so I think the added complexity is ok. It could even actually be welcome as an incentive to migrate to the end goal more "simple" way.

PS: pull request to add his solution to the SemanticNullability.md comparison: #1707

[benjie]

I think another key thing with @semanticNonNull is you only need it in a few key heavy traffic places for clients to feel a real benefit from it. You don't need to add it to every semantically non-nullable field (unlike @propagateError which you must add to every existing non-nullable position during migration or risk breaking existing clients), so it's IMO a much less noisy proposal.

[BoD]

I believe most systems will have more non-null fields than nullable.

I still think unadorned=nullable may lead to a tendency to use nullable where semantic non-null would be more appropriate, simply because it’s the default.

But perfect is the enemy of the good.

[martinbonnin]

Same here. I agree unadorned being non-null, like in Swift and Kotlin is a nicer end goal but after 4 or 5 years working on this, I've made my peace with it in the interest of moving forward.

We discussed it in yesterday's nullability working group and looks like this is a shared sentiment.

It doesn't have to be forever though. We can use String!/String now with transitional types and make a bigger syntax switch to String/String? for GraphQL 2.0 in N years.

[leebyron]

Yeah, I've personally fought with this one myself. I believe a majority of fields in most schema will be non nullable

I've been convinced that the footgun of: non null by default and realizing you needed nullable, but now it's a breaking change -- it's just not quite worth it.

This is a tough one

[glen-84]

I guess the problem with changing the default is that it necessitates a syntax change – if String becomes non-null, then you need to introduce another character for nullable (f.e. ?).

The one benefit of doing that now is that you can group these two (relatively large) changes together, and avoid disruption later on.

Just as a change to nullability and syntax partially invalidates existing documentation, etc., so does eliminating null propagation (over time). This could, theoretically, be combined.

It is of course a significantly larger endeavour, but it might be worth considering today if that is the desired end goal.