Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.InvalidOperationException : Invalid primitive System.Char #43

Open
zacala1 opened this issue Aug 30, 2022 · 4 comments
Open

System.InvalidOperationException : Invalid primitive System.Char #43

zacala1 opened this issue Aug 30, 2022 · 4 comments
Labels
bug Something isn't working PR welcome User contribution/PR is welcome

Comments

@zacala1
Copy link

zacala1 commented Aug 30, 2022

When I tested serializing char type property, 'System.InvalidOperationException : Invalid primitive System.Char' exception occurred.
I guess that 'private void WritePrimitive(object primitive, TomlPropertyDisplayKind displayKind)' function should deal with char type. there is no 'if (primitive is char c)' condition.

@xoofx xoofx added bug Something isn't working PR welcome User contribution/PR is welcome labels Aug 30, 2022
@xoofx
Copy link
Owner

xoofx commented Aug 30, 2022

Indeed. I have no personal incentive to fix this, but PR Welcome. It needs to handle correctly the mapping back and forth to strings and handle the case that one UTF-8 char might not be able to match to a single UTF-16 char as you would need surrogates pairs, so yeah, supporting a char is not great in the end.

@markusschaber
Copy link

As a C# "char" could be a lone surrogate, they cannot be always properly output as UTF-8 strings. On the other hand, how should the parser react to input strings which do not map to a single char, like empty strings, or strings which contain several characters?

Maybe it would be better to use the numeric value of the char and output it as an integer (treating it equal to .NET ushort / uint16)?

@lilith
Copy link
Contributor

lilith commented Feb 1, 2024

There's no 'char' type in either TOML or JSON. And .NET's strings are not even UTF-16, but rather WTF-16, so you can't make assumptions about anything being valid.

I would suggest either explicitly preventing this from working by default (requiring a custom type converter for people who want to opt into that can of worms), or serializing it as integer. Deserializing it as integer is also kind of fraught. I would error towards providing example converters for decimal/char rather than having automatic behavior that may not match assumptions.

That said, I've no particular interest in any choice made here as I won't be using char in a field. More usage case info and context would be useful to this issue.

@xoofx
Copy link
Owner

xoofx commented Feb 1, 2024

That said, I've no particular interest in any choice made here as I won't be using char in a field. More usage case info and context would be useful to this issue.

Similarly to decimal, Tomlyn should probably throw a proper exception with not supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working PR welcome User contribution/PR is welcome
Projects
None yet
Development

No branches or pull requests

4 participants