Opt-out or opt-in for build constants

[svrooij]

Is your feature request related to a problem? Please describe the problem.

The dotnet code generated has a ton of build constants (for nullability compatibility for everything pre .net3.1). Can we get rid of them? Possibly by using an opt-in if you want them (loose the years old compatibility), or by using an opt-out (and not making a breaking change for people using Kiota on anything pre .net core 3.1)

The following 9 lines will only be 2 lines, everywhere in the generated client.

#if NETSTANDARD2_1_OR_GREATER || NETCOREAPP3_1_OR_GREATER
#nullable enable
        public async Task<List<.....App>?> GetAsync(Action<RequestConfiguration<....Apps.AppsRequestBuilder.AppsRequestBuilderGetQueryParameters>>? requestConfiguration = default, CancellationToken cancellationToken = default)
        {
#nullable restore
#else
        public async Task<List<......App>> GetAsync(Action<RequestConfiguration<.....Apps.AppsRequestBuilder.AppsRequestBuilderGetQueryParameters>> requestConfiguration = default, CancellationToken cancellationToken = default)
        {
#endif

Client library/SDK language

Csharp

Describe the solution you'd like

I would like to see all the build constants gone. I mean dotnet core 3.1 stopped being supported almost 2 years ago, so I think it's time to say goodbye to it.

And developers still targeting anything that doesn't support nullability might still want to opt-in to have code they can build by adding an optional parameter (but this would be a breaking change for them).

Additional context

No response

[baywet]

Hi @svrooij.
Thank you for bringing this up. The main reason why we have conditions here is because the code we generate is compatible with C# 7 .1
This is so we are compatible with net framework which was one of the requirements when we originally built the C# generation.
We've had many discussions on the topic over the last two years see the following issues:

• [Multiple languages] properties are generated as nullable/optional, despite required/nullable usage in OAS schema #3911
• Avoiding proliferations of ifdefs for nullable types #4255

I don't think there is much value into rehashing the same arguments over again come up we're unlikely to change any of that before a new major version.
Let us know if you have further questions or comments.

[svrooij]

Backwards compatibility can be accomplished by implementing this as opt-out, which would not break any existing functionality. I envision something like --nullable-compatible which would tell the generator yes I know I want opt-out of the old stuff.

But as discussed this would result in 50+ permutations. I was not able to find the previous issue because I search for the wrong key words, closing this one and following along the other issue.