int | missing | absent

[Steven Schveighoffer]

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.

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

Well, in D you need reserve a place to hold it if present, or provide a 
bucket to put it in (i.e. a JSON type).

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

This is, in fact, the JSON algebraic type, which is present in most JSON 
libraries.

> 
> When implementing rich REST services (with some complexity), undefined 
> native management is a must (and not the same than null management).

Yes, `null` in the stream is different than missing. But again, most 
people would rather deal with concrete types rather than a dynamic JSON 
type.

The iopipejson library does not really have a type for this, but it 
would be a useful addition.

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

Yeah, I can see that you would have to make a custom serialized option. 
Though, doing this via a type is possible, without having to write 
custom serialization for all entities.

Maybe you can provide an example, and there may be a solution that you 
haven't thought of.

-Steve