Fix some unused parameters warnings

[makekryl]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @makekryl, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on improving code hygiene by addressing compiler warnings for unused function parameters. By adding the [[maybe_unused]] attribute, the changes ensure that the codebase compiles cleanly under strict warning settings without altering any functional logic.

Highlights

• Compiler Warnings: Applied the [[maybe_unused]] attribute to several function parameters that are intentionally unused, effectively suppressing compiler warnings related to these parameters.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request fixes several unused parameter warnings by adding [[maybe_unused]]. While this is the correct approach for Parser_basic_type.hpp and Writer.hpp, in OneOf.hpp it appears to hide a potential logic issue. The unused parameter _result should likely be used instead of _value for correctness, as it contains the result of the validation. I've left a specific comment with a suggestion for this.

[gemini-code-assist]

While [[maybe_unused]] silences the compiler warning, it seems to hide a potential logic bug. The parameter _result contains the value from Head::validate(_value) and should be returned on success, not the original _value. This is more robust, as the validation step could potentially modify the value. The existing comment on lines 50-51 also suggests this is the intended logic.

I recommend using _result and removing the [[maybe_unused]] attribute.

Suggested change

	.and_then([&]([[maybe_unused]] auto&& _result) -> rfl::Result<T> {
	if constexpr (sizeof...(Tail) == 0) {
	if (_errors.size() == sizeof...(Cs)) {
	return _value;
	.and_then([&](auto&& _result) -> rfl::Result<T> {
	if constexpr (sizeof...(Tail) == 0) {
	if (_errors.size() == sizeof...(Cs)) {
	return std::forward<decltype(_result)>(_result);

[liuzicheng1987]

@makekryl , thanks for the PR.

In these three instances, instead of writing [maybe_unused], could you simply get rid of the variable name of the unused parameter.

So instead of

([maybe_unused] auto&& _var)

Just type

(auto&&)

That is what we do in the rest of the codebase and it is also more concise.

[makekryl]

I thought [[maybe_unused]] is preferred, as it was introduced to some other pieces of code in a similar PR (#547), it also seems quite less misleading than unnamed parameters though, IMO to_schema would be a little bit confusing without the argument name

I can also remove those [[maybe_unused]] too in this PR if you want to stick with unnamed parameters, what do you think?

[liuzicheng1987]

@makekryl , sure, go ahead.