HipJSON: A high performance implementation of JSON parser with std.json syntax. Used by Redub and Hipreme Engine

[Zz]

On Thursday, 30 October 2025 at 13:02:16 UTC, Hipreme wrote:
> On Thursday, 30 October 2025 at 12:16:36 UTC, Dennis wrote:
>> On Thursday, 23 October 2025 at 01:50:55 UTC, Hipreme wrote:
>>> Hope you guys enjoy it :)
>>>
>>> https://code.dlang.org/packages/hipjson
>>
>> Very nice! I wonder why you chose to follow std.json's 
>> interface with dynamic objects, rather than an introspection 
>> based `parseJson(T)(ref T obj, string jsonData)` which fills a 
>> struct/class T with values from the json text, ignoring 
>> unknown keys.
>>
>> Can this become a std.json replacement in Phobos v3 (or even 
>> v2)?
>
> Redub uses a cache system in which the hash of an object 
> becomes a key. This does not translate well to structs as they 
> are "random" keys.
>
> Beyond that, dub also does use platform filters such as 
> "dflags-ldc". In which one can make arbitrary combinations, 
> which is also a problem. That being said, dynamic objects are 
> way more flexible.
>
> Another use-case where it doesn't fit very well is for 
> representing file system. Since the filesystem contents are 
> dynamic, that is another reason. This is used for checking 
> valid accessible files in my wasm API.
>
> There is another case in which the dynamic type API is kinda 
> important, which is mostly when you do union types, so one 
> would still need a good representation of it:
>
> ```json
> "directionals": {
>         "move": {
>             "x": [
>                 {"keyboard": "a", "gamepad": "dPadLeft", 
> "value": -1},
>                 {"keyboard": "d", "gamepad": 
> "dPadRight","value": 1},
>                 {"analog": "left", "axis": "x"}
>             ],
>             "y": [
>                 {"keyboard": "w", "gamepad": "dPadUp", "value": 
> -1},
>                 {"keyboard": "s", "gamepad": "dPadDown", 
> "value": 1},
>                 {"analog": "left", "axis": "y"}
>             ]
>         }
>     }
> ```
>
> For my input API, it also receives arbitrary actions which can 
> be referenced to the player, and in an array of an union type 
> of either a value or an axis. Really complicates the algorithm. 
> And also I wanted a std.json API since I was already using it 
> in my projects, so it makes it much easier to migrate.
>
> As a final input, I also don't really like using templated 
> code. It is also very easy to create a deserialization function 
> based on a struct, so, if one day I decide to add that API, it 
> will be a 0 effort migration.

Thanks for hipjson.

Zz