Uh oh!
There was an error while loading. Please reload this page.
Add json support for F# options, lists, sets, maps and records - #55108
Conversation
ghost
commented
Jul 2, 2021
Tagging subscribers to this area: @eiriktsarpalis, @layomia Issue DetailsContributes to #29812. Note that the changes do not include support for discriminated unions since it requires infrastructural changes touching on polymorphism support (cf. #30083). cc @dsyme@bartelink.
|
How is this going to work with trimming? Does this need an explicit public API to opt-in? |
Uh oh!
There was an error while loading. Please reload this page.
eiriktsarpalis
commented
Jul 3, 2021
The feature requires unreferenced code to function, so it can break when used with trimming. There is precedent for this, for example the converters for System.Collections.Immutable that intentionally don't take a static dependency to the types.
Maybe, but I don't see why it shouldn't be the default. The current handling of F# types is broken one way or another. |
jkotas
commented
Jul 3, 2021
It is not pay-for-play. Every Json serializer construction is going to pay to the FSharp checks now. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
eiriktsarpalis
commented
Jul 3, 2021
Of course, but that argument could be made for other rarely used supported types like IAsyncEnumerable and System.Collections.Immutable. We can measure the impact of adding F# checks to warmup time and make a call based on that, however my expectation is that users conscious of startup times will switch to source generators. |
eiriktsarpalis
commented
Jul 3, 2021
Misc user feedback collected from social media:
|
En3Tho
commented
Jul 3, 2021
Aren't records supported by default in net5? I've even forked fsharp.stj repo to use record (de) serialization out of the box. |
They generally happen to work, however struct record deserialization is currently broken. This change fixes that particular corner case and makes support official by adding tests for all record kinds. |
En3Tho
commented
Jul 4, 2021
Nice. Thank you for clarification. |
dsyme
commented
Jul 5, 2021
@eiriktsarpalis How about single case unions, list types, option types, are they covered? |
eiriktsarpalis
commented
Jul 5, 2021
Hi @dsyme, options and lists are supported special cases but other DUs have not been added yet. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
3f96c58 to
dd78c62Compareeiriktsarpalis
commented
Jul 12, 2021
FWIW I wrote a benchmark comparing cold start serialization for main and the PR branch: https://gist.github.com/eiriktsarpalis/ecb9259ee92940469d19989f81383dfd. Running statistical tests with 3% threshold seems to indicate no notable performance regressions. |
Uh oh!
There was an error while loading. Please reload this page.
e3aef95 to
2e79342Compare011b5ff to
89cf0ceCompareUh oh!
There was an error while loading. Please reload this page.
steveharter
left a comment
There was a problem hiding this comment.
LGTM; however not familiar with F# so can't comment on the value add here without the support for "discriminated unions".
Heads up: I just pushed a commit that makes discriminated unions explicitly throw |
eerhardt
commented
Jul 13, 2021
The trimming annotations LGTM. |
d6cc6cd to
f4bdfdaCompareThis reverts commit 2e793422dca84bd22d55cdfa2cd6c9b6c5d4963e.
f13a21d to
17a76a0Compareghost
commented
Jul 15, 2021
Hello @eiriktsarpalis! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me ( |
Contributes to #29812 by adding support for the following types:
Note that the changes do not include support for discriminated unions, attempting to serialize a DU will now throw
NotSupportedException. See #29812 (comment) for an explanation why we're doing this. We can revisit this approach in future releases of .NETcc @dsyme@bartelink.