[swift2objc] Support default param values

[liamappelbe]

func someFunction(parameterWithoutDefault: Int, parameterWithDefault: Int = 12) {

The wrapper API should have the same default value (possibly converted to a wrapper type).

[DPrakashhh]

I have submitted a PR to address this issue.
The implementation follows a method-overloading strategy to bridge the gap between Swift’s default parameters and Objective-C’s lack of native support for them.

How this solves the issue:
1- Overload Generation: The transformer identifies trailing parameters with default values and generates $N$ overloads. This allows Objective-C consumers to call the wrapper with fewer arguments, which then triggers the original Swift function using its native defaults.
2- Symbol Graph Parsing: Updated the parser to extract default value expressions from declarationFragments, supporting both simple and multi-token values.
3- Breadth of Support: The logic is applied across global functions, class methods, and initializers.
4- Initializer Handling: Includes specific logic to handle @objc override public init() cases where all parameters have defaults.

The solution includes new unit tests for the parser and an integration test fixture. All 70 integration tests are currently passing.

[liamappelbe]

One complication in Swift that I didn't consider is named params vs unnamed params, and how they interact with default params.

In most languages, default params have to appear at the end of the param list, and if there are multiple default params, then you're only allowed to omit params at the end of the list (ie if you have default params A, B, C, and you want to specify B, you must also specify A).

The same goes for unnamed params in swift, but named params don't have these restrictions. Named params with default values can appear anywhere in the param list, and you can specify/omit multiple default named params in any order you like.

ObjC methods (and @objc annotated Swift methods) don't support default values, so we have to convert them to overloads. For N default params we have to define N+1 different methods, that omit them one at a time. Or at least that's the approach for unnamed params. Since named params don't have that ordering restriction, to be fully correct we'd actually have to specify 2^N different methods, omitting every possible combination of params. But this would be a bit silly, so I think we should ignore all that and just treat all default params as if they have the ordering restriction.

---

Another complication is that @objc annotated init methods actually do support default params, and will auto-generate the multiple different overrides under the hood. But for code consistency I think we should ignore this convenience and just treat init methods like any other methods.

---

Another complication is that Swift default values can be expressions. They don't have to be compile time constants, and can even have side effects, though there are some restrictions about what they can access. This complication we can't really ignore.

[DPrakashhh]

Thank you for the detailed breakdown, Liam sir!

As a second-year student, I want to be honest—some of the edge cases you mentioned (like the 2^N vs N+1 overload complexity) were quite new to me. I spent some time researching the Swift documentation and used AI as a tutor to help me break down the architectural trade-offs you were suggesting. It was a great learning experience, and I now feel much more confident in why the N+1 approach is the right choice here.

I have updated the PR to address all of your points:
1- Overload Generation: Implemented the N+1 strategy for methods, initializers, and global functions to avoid the 'silly' 2^N bloat while maintaining a predictable ordering restriction.
2- Tokenizer Refactor: Moved the token-splitting logic into TokenList.splitToken and added = to the splittables list. It now handles pulling delimiters off the end of tokens correctly.
3- Expression Support: Verified that by grabbing default values as strings, the Swift wrapper naturally handles non-constant expressions (like 10 * foo) at runtime.
4- Resiliency: Added a check to protect string literals from being split and included the 'evil string' test case containing
) -> .
5- Code Hygiene: Replaced manual ID generation with addIdSuffix and ensured everything passes dart format and dart analyze.

All 75 tests are passing. I really appreciate the mentorship on this one. Ready for your final review!