taking a shot at #2456

Cool. I guess we're going with extract_into out of all of those ideas.

Then let me expand on the idea and see if any of these ideas are any good:

// call `setMake` and `set_model` member functions
obj.extract_into<"make:setMake", "model:set_model">(car);

// extract "user"."name" and put it into "username" field
obj.extract_into<"user.name:username">(user);

// extract the first driver and call "setDriver" with that
obj.extract_into<"drivers.0:setDriver">(car);

// extract the first driver and call "setDriver" on `drivers` member field with that
obj.extract_into<"drivers.0:drivers.setDriver">(car);

You get the gist, this is pretty much a custom DSL which we could even generalize even more by instead of a string, we make it something more structured or even a function that returns something structured, and the string would simply be converted to that struct before things happen.

But I kinda don't like the idea of designing a custom DSL or even a full query language for SIMDJSON just yet.

But I do see the potential of this, and I don't want to waste this potential by under-generalizing it, and at the same time, over-generalizing it may backfire just as easily.

What do you guys think?

Also, question: will this work with custom deserializable types? If Car had a tag_invoke, we could just use it in User{ Car car; } for example, and it would work, right?

Also, question: will this work with custom deserializable types? If Car had a tag_invoke, we could just use it in User{ Car car; } for example, and it would work, right?

It should !!! Of course, it might be beneficial to include a test, but I don't see why it would not work.

Then let me expand on the idea and see if any of these ideas are any good:

That's cool. I really like:

// extract "user"."name" and put it into "username" field
obj.extract_into<"user.name:username">(user);

Could even be...

// extract "SomeField" and put it into "username" field
obj.extract_into<"SomeField:username">(user);

This seems quite elegant and could even be used more generally in the generic get<>() method, and maybe in the simdjson::from construction (although, this would require some engineering).

I think it is much more elegant to put these instructions in the function call than to annotate one's objects.

I am less certain about the function calls that you document. Currently, rolling your own custom serialization/deserialization code is not pretty. We could/should make it more elegant... but until we have real-world feedback, I am not sure we should invest a lot of effort trying to guess what is useful.

So my question at this stage is... do we expect that what @FranciscoThiesen implemented blocks any of these future ideas ?

I think not, right? If so, if we think that we should go ahead and adopt's Francisco's idea.

I think that we should merge this and release it, but let us give it a bit of time.

We will want to extend it from object to document and add documentation. I can do this later.

@FranciscoThiesen at your convenience, please review the comments. (No rush.)

Also, question: will this work with custom deserializable types? If Car had a tag_invoke, we could just use it in User{ Car car; } for example, and it would work, right?

It should !!! Of course, it might be beneficial to include a test, but I don't see why it would not work.

Then let me expand on the idea and see if any of these ideas are any good:

That's cool. I really like:

// extract "user"."name" and put it into "username" field
obj.extract_into<"user.name:username">(user);

Could even be...

// extract "SomeField" and put it into "username" field
obj.extract_into<"SomeField:username">(user);

This seems quite elegant and could even be used more generally in the generic get<>() method, and maybe in the simdjson::from construction (although, this would require some engineering).

I think it is much more elegant to put these instructions in the function call than to annotate one's objects.

I am less certain about the function calls that you document. Currently, rolling your own custom serialization/deserialization code is not pretty. We could/should make it more elegant... but until we have real-world feedback, I am not sure we should invest a lot of effort trying to guess what is useful.

So my question at this stage is... do we expect that what @FranciscoThiesen implemented blocks any of these future ideas ?

I think not, right? If so, if we think that we should go ahead and adopt's Francisco's idea.

I tried the custom setters and also nested fields, but that didn't work out well on a first attempt. Also not sure if the p2996 has support for every predicate that is described in the P2996 paper (R13). I believe it's worth keeping an issue open for that and trying again later on, maybe with more mature compiler support (or on a day with divine inspiration)