You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This applies to the current version from source control.) Consider this type:
[< NamedUnionCases>]typetestType=| Float ofFloat:float| Prod ofProd1:testType*testType| Sum ofSum1:testType*testType
I'm not 100% certain of what is supposed to happen when calling WebSharper.Json.Deserialize on this, according to http://websharper.com/docs/json#heading-3-4-2, because I'm not sure whether a different name is sufficient to satisfy the requirement for a unique field. Still, I would expect it to either succeed and work correctly, or fail with a compiler error.
Instead, compilation is successful but the resulting deserializer fails when invoked. This is the full repro case, where I attempt to do a round trip and test whether it works:
Note that removing the Sum case results in the test succeeding, even though it isn't used anywhere.
Fortunately, there is a simple workaround. If I give a name to the second member of each tuple type, then everything works. So this isn't a major problem.
The text was updated successfully, but these errors were encountered:
Indeed it seems that the deserialization algorithm to find the unique field to use is faulty. Looking at the compiled code, it deduces that it's a Sum if it has an Item2, which Prod also has, when it should look for Sum1 instead.
Just a tiny request: please-please, use proper markdown formatting for code snippets (indent by at least 4 spaces, or wrap in triple-ticks), otherwise the parent issue will end up looking horrible on the WebSharper forums page. Thanks!
(This applies to the current version from source control.) Consider this type:
I'm not 100% certain of what is supposed to happen when calling
WebSharper.Json.Deserialize
on this, according to http://websharper.com/docs/json#heading-3-4-2, because I'm not sure whether a different name is sufficient to satisfy the requirement for a unique field. Still, I would expect it to either succeed and work correctly, or fail with a compiler error.Instead, compilation is successful but the resulting deserializer fails when invoked. This is the full repro case, where I attempt to do a round trip and test whether it works:
Note that removing the
Sum
case results in the test succeeding, even though it isn't used anywhere.Fortunately, there is a simple workaround. If I give a name to the second member of each tuple type, then everything works. So this isn't a major problem.
The text was updated successfully, but these errors were encountered: