String field cannot be optional.

[yuto-katsuragi]

Description

Primitive Types can be optional.
but string field can not be optional.

Repro steps

1. Step A
   provide following this in swagger yaml

      number_value:
        type: number
        nullable: true
      string_value:
        type: string
        nullable: true

2. Step B

read property by SwaggerProvider

type Provider = SwaggerProvider<schema, PreferAsync = true>
let client = Provider.Client()
let result = client.Operation() |> Asnyc.RunSynchronously

let numberValue = result.NumberValue // ==> the type is option float
let stringValue = result.StringValue // ==> the type is string

Expected behavior

nullable string field should be Option type.

Actual behavior

nullable string field is not Option type.

Known workarounds

• null checking

Related information

• Operating system
  Windows 10
• NuGet Version
  0.10.0-beta05
• .NET Framework 4.7.2

[sergey-tihon]

This is by design. string in .net is nullable type.
I do not see benefits of generating Option<string>

So, technically speaking, the issue is that we model

string_value:
        type: string
        nullable: false

as string that can be null in runtime.
But there is no easy way to provide not nullable string.

[yuto-katsuragi]

There are several facts.

1. string in .NET is nullable type
2. string and null are different types in JSON

It can be understood that null can not be removed. (by 1.)
but I see benefits as reflect intention as option . (by 2.)

Similar situations.

SQL Server has intended to be null (NULL Column)
and Popular Type Provider takes care of it.

https://github.com/fsprojects/FSharp.Data.SqlClient

this library type following.
varchar NULL in DDL -> string option in .NET

I think so.
Even if can not remove null, can reflect intention as option

Honestly, there is a problem of preference.
But I think the string option is worth it.

[weebs]

I came here to post about the same thing, it'd be really helpful to have this as an option like we do with IgnoreOperationId, at least in my case.

I have a RESTful API serving data from SQL where some columns are nullable text while others are not. A lot of these endpoints serve basic CRUD operations, and so I made a generic editor that uses reflection on the client generated by SwaggerProvider to save myself time from coding each one by hand. Unfortunately I don't really see a good way to determine which strings are actually nullable and which are not, so I can't easily communicate that through the generic editors (and pretty much every one has a mixture of non-nullable and nullable strings)

While .NET does have nullable strings, if the spec is communicating that they're non-nullable, I think it makes sense to try and conform to the spec as close as possible with an option type.

[Numpsy]

But there is no easy way to provide not nullable string.

Now that we have nullability annotations, is possible for a type provider to mark a generated string property as nullable or none-nullable?

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the continued interest in this issue, and good question @Numpsy!

Current Behaviour (why strings don't get Option(T))

In both v2 (DefinitionCompiler.fs) and v3 (DefinitionCompiler.fs), the wrapping logic at the end of compileBySchema / compileSchemaObject is:

if isRequired then
    tyType                        // required → return as-is
else if tyType.IsValueType then
    Option(T) or Nullable(T)     // optional value type → wrap
else
    tyType                        // optional reference type → return as-is

string is a .NET reference type (IsValueType = false), so it falls into the third branch and is returned unwrapped. Value types like bool, int, float, DateTimeOffset (and, after a fix landing soon, DateOnly) are wrapped in Option(T) when optional/nullable.

The original design rationale (see sergey-tihon's 2019 comment) is that string in .NET is already nullable by CLR design, so Option(string) adds a second layer of "might be absent" on top of "might be null"—not always helpful.

Addressing the NRT Question (@Numpsy, Feb 2026)

.NET Nullable Reference Type (NRT) annotations are metadata stored in custom attributes ([NullableAttribute], etc.). The ProvidedTypeDefinitions infrastructure in the FSharp.TypeProviders.SDK does not currently expose a first-class API for emitting those attributes on generated properties, so type providers cannot easily mark generated string properties as string? vs string at the NRT level today.

The Practical Fix

The most tractable path is to wrap nullable strings as Option(string) — analogous to how FSharp.Data.SqlClient maps varchar NULL → string option. The change would be surgical: add a case in the wrapping logic:

else if tyType = typeof(string) && not isRequired then
    ProvidedTypeBuilder.MakeGenericType(typedefof(Option(obj)), [tyType])
else
    tyType

Trade-off: this would be a breaking change for any existing user who currently reads a nullable-string field as a plain string. It would need to be gated behind a new static parameter (e.g., WrapNullableStrings=true) or a major version bump.

If there is appetite for this change a new issue or PR would be a good next step to discuss the right approach.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f