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.
-Steve
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
It isinefficient in memory terms (because D offers only
"structs", not the Typescript object equivalent where properties
accepts to be not present nativelly as part of the type
definition)
But it is, in my opinion, a needed feature: What if you want to
"patch" an entity or query an entity requiring only some of the
properties?... I don't want to build results using Json
objects... D is typed language and results should be built in a
rich typed structure (like: {id:"1324123", name:"peter",
age:18} or {id:"1234123", age:18 } **validated by compiler**.
When implementing rich REST services (with some complexity),
undefined native management is a must (and not the same than null
management).
I am currently using vibe-d json and the way it manages @optional
forces me to write custom serialization for all entities (to
properly manage undefined vs null)... it is anoying!!!
