Permalink
Reply
On Monday, 27 June 2022 at 23:05:46 UTC, Steven Schveighoffer wrote:
>On 6/27/22 9:03 AM, Antonio wrote:
>On Wednesday, 22 June 2022 at 01:09:22 UTC, Steven Schveighoffer wrote:
>On 6/2/22 9:24 AM, bauss wrote:
I feel it's too loose to make a best effort, and leave the rest up to initial values, or just ignore possibly important information during parsing.
May be for your case Steve.
I need to represent in a "typed" way complex structures where some properties can be "undefined" (not present in json) and where null value is a valid value (and not the same that "undefined" ones)... basically, the algebraic type Undefined | Null | T
I see what you are saying. What needs to happen is first, you need a type wrapper that does this, which defaults to undefined. Then mark it optional so it's OK if it doesn't appear. Then only if the field is not present will it be marked as undefined.
It may even be useful to make the type wrapper itself always optional, rather than having to mark it optional.
Exactly.
This issue/example in vibe-d treats about this solution and the annoying change of behavior treating "null" when @optional attribute is present:
https://github.com/vibe-d/vibe.d/issues/2673
The code is a "simplification" of something more complex (Special wrappers for Null | T, Undefined | T and Undefined | Null | T with some functional stuff for match! and null-safe access (well, trying to: It's really complex and I'm not enought experienced).
I Tried to base my solution in SumType, but I didn't know how to add the required fromRepresentation/toRepresentation methods for custom serialization/deserialization...