question about library conventions and std.json quirks

[spare root]

I’m working on a basic gql client for zig but these questions really apply to any sort library design that uses std.json as an impl detail

• I’m struggling with whether or not it makes sense to bubble up std.json.Parsed wrapper types in my pub interface. I’ve run into a number of runtime segfault issues with calling parsed.deinit and then passing value up to the caller. This feels like implementation detail leakage https://github.com/softprops/zig-graphql/blob/a34adc2dd88db89f0a884daaa85af956b271d1e5/src/main.zig#L114. Is there a better way to do this?

• I’ve run into a number of related runtime segfault issues when the alloc option of json parser api is set to the default https://github.com/softprops/zig-graphql/blob/a34adc2dd88db89f0a884daaa85af956b271d1e5/src/main.zig#L172. I’ve only been able to get reliable results with alloc_always which makes me feel I’m trading off something potentially good for better runtime predictability. Is there a better way to do this?

[rigid saffron]

I mean, you shouldn't be getting segfaults at all, so if you are then yes, there's a better way to do things.

You can't deinit parsed and then return the value. I agree with you though, I hate std.json.Parsed(T). I don't see why it's in std.json, just call it std.Owner(T) or something. I realize that's superficial, but at least then it's leaking that value is owned by Owner, instead of being something related to JSON.

If you use the default, alloc_if_needed, and you're using parseFromSlice, then the lifetime of the returned data will be tied to the input (for strings at least).

While the AllocWhen does make things more complicated, it's also nice control to the caller. There's no way for Zig to know what the lifetime of the input slice is. It could safely always use alloc_always, but that would result in extra allocations for the relatively common case that the input and the parsed json have the same lifetime.

[spare root]

Agree on the Owned type thing. One idea I had was to wrap everything in my own type that when deinit is called I could deinit the json parsed type. That feels like it would be so common to so many cases that I’m surprised this std lib generalization doesn’t already exist. This also makes me miss rusts Drop trait a bit