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...
