feat: Overload client functions

[NeaguGeorgiana23]

This PR

• Adds EvaluationOptions overloads for all typed flag evaluation methods (GetBooleanValue, GetStringValue, GetIntegerValue, GetDoubleValue, GetObjectValue) in the Features interface and ClientAPI implementation per OpenFeature Specification Requirements 1.3.1.1 and 1.5.1.
• Supports both (flag_key, default_value, options) and (flag_key, default_value, context, options) call signatures.
• Updates ClientAPI::EvaluateFlag and private typed evaluation helpers to accept and propagate std::optional<EvaluationOptions>.
• Adds :evaluation_options dependency to the :features library target in openfeature/BUILD.
• Adds unit tests in test/client_api_test.cpp verifying each typed evaluation method with EvaluationOptions and combined EvaluationContext + EvaluationOptions.

Related Issues

Fixes #128

Notes

• These overloads enable passing invocation-specific hooks (options.hooks) and metadata hints (options.hook_hints) to individual evaluation calls.

Follow-up Tasks

• Implement the full hook execution lifecycle in ClientAPI::EvaluateFlag to execute invocation-level hooks and propagate HookHints.
• Add detailed flag evaluation methods (Get*Details) returning `Flag

[coderabbitai]

📝 Walkthrough

Walkthrough

EvaluationOptions overloads were added to Features and ClientAPI for all supported flag types. Client evaluation now forwards options through the shared pipeline. Tests cover option-only and context-plus-options calls.

Changes

EvaluationOptions evaluation support

Layer / File(s)	Summary
EvaluationOptions API contracts openfeature/features.h, openfeature/client_api.h	The public interfaces add evaluation overloads for boolean, string, integer, double, and object values.
Option propagation through evaluation openfeature/client_api.cpp, openfeature/BUILD	Client getters and typed evaluators forward options to EvaluateFlag. The Bazel target adds the required dependency.
Overload coverage tests test/client_api_test.cpp	Tests cover option-only and context-plus-options calls for every supported flag type.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Features
  participant ClientAPI
  participant EvaluateFlag
  participant ProviderCallback
  Features->>ClientAPI: request flag value with EvaluationOptions
  ClientAPI->>EvaluateFlag: pass context and options
  EvaluateFlag->>ProviderCallback: dispatch typed evaluation with options
  ProviderCallback-->>ClientAPI: return evaluation result

Loading

Possibly related PRs

• open-feature/cpp-sdk#120: Adds the EvaluationOptions type used by these evaluation APIs.
• open-feature/cpp-sdk#121: Integrates EvaluationOptions into OpenFeature API targets.
• open-feature/cpp-sdk#127: Modifies the same client, feature, options, build, and test areas.

Suggested reviewers: oxddr, m-olko

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the primary change by stating that client functions receive overloads.
Description check	✅ Passed	The description clearly explains the EvaluationOptions overloads, propagation updates, dependency change, and tests.
Linked Issues check	✅ Passed	The changes satisfy issue #128 by adding EvaluationOptions overloads across the Features and ClientAPI evaluation methods.
Out of Scope Changes check	✅ Passed	The build, API, implementation, and test changes directly support the EvaluationOptions overload objective in issue #128.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@openfeature/client_api.h`:
- Around line 102-109: Remove one duplicate declaration set for AddHooks,
AddHook, and GetHooks in ClientAPI, retaining exactly one declaration of each
method with its existing signatures and override specifiers.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 72258ec3-7646-44db-9ace-43f58c46c062

📥 Commits

Reviewing files that changed from the base of the PR and between 72d4c91 and 3f148a2.

📒 Files selected for processing (5)

• openfeature/BUILD
• openfeature/client_api.cpp
• openfeature/client_api.h
• openfeature/features.h
• test/client_api_test.cpp

[coderabbitai]

🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

ast-grep outline openfeature/client_api.h --match ClientAPI --view expanded
sed -n '95,120p' openfeature/client_api.h

Repository: open-feature/cpp-sdk

Length of output: 1413

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

sed -n '1,185p' openfeature/client_api.h
printf '\nDuplicate declarations:\n'
python3 - <<'PY'
from pathlib import Path
import re

text = Path("openfeature/client_api.h").read_text()
patterns = [
    r'void AddHooks\(std::vector<std::shared_ptr<GeneralHook>> hooks\) override;',
    r'void AddHook\(std::shared_ptr<GeneralHook> hook\) override;',
    r'std::vector<std::shared_ptr<GeneralHook>> GetHooks\(\) const override;',
]
for pattern in patterns:
    matches = list(re.finditer(pattern, text))
    print(pattern, "count=", len(matches),
          "lines=", [text.count("\n", 0, m.start()) + 1 for m in matches])
PY

printf '\nAvailable C++ compiler:\n'
command -v c++ || true
command -v g++ || true

Repository: open-feature/cpp-sdk

Length of output: 8684

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '%s\n' 'struct Base { virtual void f() = 0; };' \
              'struct Derived : Base { void f() override; void f() override; };' \
              'int main() { return 0; }' |
  c++ -std=c++17 -fsyntax-only -x c++ -

printf 'standalone duplicate-member declaration accepted\n'

Repository: open-feature/cpp-sdk

Length of output: 260

---

🌐 Web query:

C++ standard duplicate identical member function declarations in the same class allowed or ill-formed

💡 Result:

In C++, declaring the exact same member function twice within the same class definition is generally ill-formed, as the C++ standard explicitly states that a member shall not be declared twice in the member-specification of a class [1][2]. However, this rule is subject to specific nuances and exceptions: 1. Overloading vs. Redeclaration: If you declare two member functions with the same name, they are not necessarily "duplicates." If their parameter-type-lists or cv-qualifiers differ in ways that allow for function overloading, the compiler treats them as separate overloads rather than a forbidden duplicate declaration [3][4]. The program only becomes ill-formed if the signatures are identical (or equivalent) in a way that does not constitute valid overloading [5][3]. 2. General Rule for Entities: Under the general rules for conflicting declarations in C++, two declarations in the same scope cannot reintroduce the same entity unless they are compatible (e.g., in the case of overloading) [5][6]. If two declarations for the same member function appear in the same class scope and have identical signatures, it is considered a redeclaration of the same entity and is ill-formed [5][3]. 3. Exceptions: The standard provides limited exceptions where a member may be redeclared. For example, nested classes or member class templates can be declared and then later defined [1][4]. Additionally, an enumeration can be introduced with an opaque-enum-declaration and later redeclared with an enum-specifier [2][4]. These exceptions do not apply to standard member functions. In summary, attempting to provide an identical declaration for a member function in the same class will cause a compiler error because it violates the restriction against declaring the same member multiple times [1][2]. If you intended to overload the function, you must ensure the signatures differ sufficiently according to C++ overload resolution rules [3][4].

Citations:

• 1: https://eel.is/c++draft/class.mem.general
• 2: https://timsong-cpp.github.io/cppwp/std23/class.mem.general
• 3: https://timsong-cpp.github.io/cppwp/std20/over
• 4: https://cplusplus.github.io/CWG/issues/2979.html
• 5: https://cppreference.net/cpp/language/conflicting_declarations.html
• 6: https://cppref.node4good.org/cpp/language/conflicting_declarations.html

---

Remove the duplicate hook declarations.

ClientAPI declares AddHooks, AddHook, and GetHooks twice with identical signatures. This makes the class definition ill-formed and blocks compilation. Remove either declaration set.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openfeature/client_api.h` around lines 102 - 109, Remove one duplicate
declaration set for AddHooks, AddHook, and GetHooks in ClientAPI, retaining
exactly one declaration of each method with its existing signatures and override
specifiers.