[Ayuse]

Explore C++ std::vector overloads in Rust for constructors, resize, and erase. Document the bridge limitations, demonstrate constructor and receiver conflicts in compile-fail examples, and record the results in the compatibility table.

1. Write Rust wrappers for that C++ type, for 3-5 different overloaded method names:
   • Create a new file named after your type in overloading-macros/cpp-overload-test/src/stdcpp
   • Wrap constructors first, writing tests to make sure the correct constructor is called
   • Explain any potential compatibility issues in a Limitations doc section
   • Explain usability issues in an Ergonomics doc section
   • Check that you have implemented all the overloads for each method name, or documented why you can't
   • Push your changes and wait for a review
2. Add a separate example with some failing overloads
   • Create a new file named after your type in overloading-macros/cpp-overload-test/examples
   • Wrap accessor/modifier methods
   • Explain how they fail in an Incompatibilities doc section
   • Explain how the overload failures could be resolved in a Workarounds doc section
   • Optional: If there's a C++ feature with no equivalent in Rust, explain that in an Inexpressible Overloads doc section
   • Push your changes and wait for a review
3. Update the overload macro compatibility table Markdown doc
   • If you haven't checked some kinds of overloads, put a ？in those squares
   • Push your changes and wait for a review

AI disclosure: Codex helped to explain and understand the problem, then gave conceptual solution.

[teor2345]

It looks like you're missing some overload sets (we want 3-5 different function names), and some overloads within those sets (we want all of the possible overloads).

Please focus on completing this PR so you make it through all 3 steps before the application period ends.

[Ayuse]

It looks like you're missing some overload sets (we want 3-5 different function names), and some overloads within those sets (we want all of the possible overloads).

Please focus on completing this PR so you make it through all 3 steps before the application period ends.

Added both resize overloads and both erase overloads, bringing the working example to three overloaded method names: new, resize, and erase. Erase uses checked Rust indices and returns an index, with that adaptation documented.

[thunderseethe]

I'm not sure this was intended, but I think we probably don't want the edits made to this file

[teor2345]

We're not ready for edits yet, but we can just ignore them for now 🙂

Editing this file is step 3, we are currently at the end of step 1, at the "wait for review" stage.

[Ayuse]

Understood, I moved ahead of the review stages. I’ll wait for step 1 to be reviewed before proceeding with steps 2 and 3.

[thunderseethe]

It looks like there might have been a version control snafu? Is it expected that these are todo!()?

[teor2345]

The examples are test files that show that overloads conflict in Rust (or can't be implemented in C++). So todo!() is ok here, there's not much point filling in the C++ code when the Rust code will never work.

See the example code here where the overloads conflict when T is size_t:

overloading-macros/cpp-overload-test/examples/stdcpp-forward-list.rs

Lines 34 to 40 in 2389011

	// This overload set has overloads which are incompatible when `T` is `c_size_t`.
	overload! {
	impl StdForwardListT {
	/// Construct a list with `count` default-constructed items.
	fn new(_count: c_size_t) -> StdForwardListT {
	todo!()
	}

Think of them like a cheap version of Rust compiler UI tests, they also come with a stderr output file.

Also, this is step 2 of the PR, this is @thunderseethe's decision. If he thinks that the step 1 work is complete, he can move on to reviewing step 2.

[Ayuse]

Yes, these were intentional placeholders in the compile-fail example, not a version-control mistake. The test checks conflicting signatures, so the bodies never run.

[teor2345]

Just a reminder to move on to steps 2 & 3 in the PR description, and make sure they are up to date with your latest code changes.

Applications must be submitted to Outreachy by Monday 9 November, please include this PR and any other Rust PRs you've done in that time.