How should I handle a potentially ISpanFormattable type?

[mburbea]

I have a generalization that I'm using for several different geospatial database formats (gdb, shpfile, etc) that represents a field on a row.
I use abit of indirection magic with a Token<T> type to encode the C# type and that allows me to write a fairly simple ISpanFormattable for valueTypes which is pretty much most of what I'll encounter, but there are also Strings that I need to worry about. I'm using this primarily for Sep, so that I can read data stored in this terrible format and just basically go Sep.Format(row[i]). Where row[i] returns one of my DbFields. Unfortunately, this doesn't work with strings, as strings are not ISpanFormattable. Should I explictly test if the field is a string? What is the best way to handle this?
Here is a rough idea of what I'm doing:
https://gist.github.com/mburbea/e8c67264899da5a35c0c9ab5ba54d6fc

[lilinus]

Perhaps an approach would be to use IFormattable as a a fallback. string implements it and ISpanFormattable inherits from it.

Here is the rejected API suggestion to implement ISpanFormattable on string where there are some discussions on the matter #103176

[mburbea]

I'm aware that it was rejected, but I don't own the library to write csvs (Sep), so my code currently is basically going...

foreach(var row in table)
{
    using var _ = row; // some dbs need their row to be disposed.
    for(int i = 0; i < layer.Fields.Length; i++)
    {
        await using var csvRow = writer.CreateRow();
        if(layer.Fields[i].FieldType == FieldType.String)
        {
            csvRow[i].Set(row[i].Get<string>());
        }
        else
        {
            csvRow[i].Format(row[i]);
        }
    }
}

As I maintain this internal library, I'm wondering if I should be embedding this logic to fallback to just write it for strings in my library code (it will probably get eliminated for the valueType case which is the 99% case).
If this was just one place I wouldn't care, but I have a few projects that use this library that need to read these dbs and have to remember this logic around strings.