Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow unknown described class members with a parse option #991

Open
kiwixz opened this issue Mar 15, 2024 · 5 comments
Open

Allow unknown described class members with a parse option #991

kiwixz opened this issue Mar 15, 2024 · 5 comments

Comments

@kiwixz
Copy link

kiwixz commented Mar 15, 2024

Hi, I'd like to make the parsing of my JSON config file more or less compatible across versions.

If a new field gets added I can easily add it if not present in the json::value before parsing it to make sure value_to has anything it needs. But a parse option to default construct in this case instead of erroring would not hurt.

In a more complex case, if the config gets updated before the application parsing it value_to will complain because of size mismatch (see here). I'd like to disable this check with a parse option, because it's much harder to iterate all the described classes to make sure there are no extra properties in the JSON.

@grisumbras
Copy link
Member

So, you are suggesting a runtime option, not another type trait?

@kiwixz
Copy link
Author

kiwixz commented Mar 15, 2024

I think this makes more sense as a runtime option, it's not that the type is special but rather that I don't care when parsing it. Like allow_comments and friends.

@grisumbras
Copy link
Member

Do I understand it correctly, that you want to both allow missing fields, and allow extra fields? Or just the latter?

@grisumbras
Copy link
Member

To allow missing fields our standard solution is to use optional. Would this work for you?

@kiwixz
Copy link
Author

kiwixz commented Mar 15, 2024

Allowing extra fields is more important to me, because its much more complicated to do beforehand and doesn't raise any questions on boost::json side.

Allowing missing fields could be nice, but then you have to decide how to set them (letting them default-constructed seems an obvious solution).

I already use optionals for null values, I didn't know it worked with missing values too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants