Skip to content

Conversation

N-Olbert
Copy link
Contributor

Summary of the changes (Less than 80 chars)

  • Don`t assume default value for optional value type argument without default value
  • Detail 2

Closes #6347 (in this specific format)

Background:

This issue appears to be a side effect of #5317 and/or #4354.
If an optional value type argument was not present in the input arguments, the InputParser was changed in 5317 to emit the default value for that type.
This was necessary to avoid compilation failures as null can not be converted to the value type.

This PR removes this special handling from the InputParser and instead coalesces null arguments into the default value within the compiler itself.
This approach is very similar to how optional values are handled and allows the InputParser to correctly preserve an explicit null argument.

General note: This seems to only affects code-first types. For annotation-based types, we already have the correct nullability information, as an argument of type int? is in fact a Nullable whose default value is null.
Anyhow, for code-first types, this is not the case as f. e. BooleanType maps to the runtime-type bool instead of Nullable<bool>.

@glen-84
Copy link
Collaborator

glen-84 commented Sep 30, 2025

Can you please revert the formatting changes? 🙂

@N-Olbert
Copy link
Contributor Author

Whoops... done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistent behavior within InputParser, when parse nullable scalar value in HC 13 in compare with 12
2 participants