Lack of nullability of reference types

[charlesroddie]

Describe the bug

Properties that should be nullable are not listed as nullable if they are reference types.
For example, in a session s, s.AmountTotal is correctly Nullable<int64>, but s.ClientReferenceId is a string when it should be a string?.
Discrepancy between:

• https://docs.stripe.com/api/checkout/sessions/object?lang=dotnet

• stripe-dotnet/src/Stripe.net/Entities/Checkout/Sessions/Session.cs

  Line 95 in a18e87f

  public string ClientReferenceId { get; set; }

Presumably this library was never updated to support nullable reference types.

I would estimate it would take 2x longer to write dotnet code without nullable reference types, since for every use of a property you would need to refer to the online documentation to see if it is nullable or not and add manual casts to nullable before proceeding.

To Reproduce

1. Get a Session s
2. Type s.ClientReferenceId
3. The result is a string

Expected behavior

The result should be a string?.

Code snippets

No response

OS

Windows

.NET version

dotnet9

Library version

current

API version

current

Additional context

No response

[jar-stripe]

Hi @charlesroddie , so sorry for the delay in getting back to you! Thanks for filing this issue. We've been discussing internally and are trying to figure out the best way to support this. Unfortunately, there are some cases where nullable reference types can cause issues in our SDKs, so one option on the table would be to include optionality in the property doc string. Would that help you avoid having to switch to external documentation in the situation you describe?

[charlesroddie]

Thanks for the reply. Your suggestion would be helpful but is more of a stopgap. The expectation these days is that nullables are annotated, which has been a great step towards making dotnet type-safe. Libraries update at different speeds and I would perhaps focus on doing this in the medium-term rather than making a quick workaround. I would be surprised if there were insuperable technical problems around doing this.

[jar-stripe]

@charlesroddie thanks for the feedback, and totally understand. We have some patterns in the SDK -- returning deleted resources into the same objects that are used to represent active resources, for example -- that make this harder than you think; either the non-nullable types would be unreliable, or every reference would have to be marked nullable. Neither seems particularly ergonomic, so a stopgap like this may be what we have to work for the short/medium term, unfortunately.