Skip to content

Conversation

@rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Dec 29, 2025

The _ identifier is treated as a keyword since Java 9, and we used to escape it to __.

The problem is that but it is somewhat likely that people will use _, __, ___ as multiple indifferent arguments, and now the identifiers will conflict. We have to pick something else.

Ideally we would look at the surrounding argument names and pick something guaranteed to be unique, but unfortunately the code isn't quite structured that way so we'll pick something unlikely to collide instead. We escape it to _under_ instead.

Changing from __ -> _under_ would be a breaking change if applied to public property names, but most likely this will be used for function parameters (unfortunately the code has been structured in such a way that property and parameter names are strongly tied together, in a way that would take more time to unwind than I care to invest right now), where it doesn't matter.


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

The `_` identifier is treated as a keyword since Java 9, and we used to
escape it to `__`.

The problem is that but it is somewhat likely that people will use `_,
__, ___` as multiple indifferent arguments, and now the identifiers will
conflict. We have to pick something else.

Ideally we would look at the surrounding argument names and pick
something guaranteed to be unique, but unfortunately the code isn't
quite structured that way so we'll pick something unlikely to collide
instead. We escape it to `_under_` instead.

Changing from `__` -> `_under_` would be a breaking change if applied to
public property names, but most likely this will be used for function
parameters (unfortunately the code has been structured in such a way
that property and parameter names are strongly tied together, in a way
that would take more time to unwind than I care to invest right now),
where it doesn't matter.
@rix0rrr rix0rrr requested a review from a team December 29, 2025 14:42
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Dec 29, 2025
if (!name) {
// toCamelCase will return an empty string from a string like `_(_+)`. Confirm that
// that is what is happening, then return the original string.
if (original.match(/^__+$/)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is not explained in the PR body - why do we need to return __ here instead of the empty string like it was?

Copy link
Contributor Author

@rix0rrr rix0rrr Dec 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because an empty string is not a valid variable name, and it leads to compiler errors.

I saw the following after my change:

public void method(String _, String , String ) {
}

We didn't have a test on this before. I have to agree I don't quite understand how this didn't trigger on real-world code that used the _, __, ___ idiom... but nevertheless this was a latent bug.

@mergify
Copy link
Contributor

mergify bot commented Dec 29, 2025

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

@mergify mergify bot added the pr/ready-to-merge This PR is ready to be merged. label Dec 29, 2025
@mergify
Copy link
Contributor

mergify bot commented Dec 29, 2025

Merging (with squash)...

@mergify
Copy link
Contributor

mergify bot commented Dec 29, 2025

Merging (with squash)...

@mergify mergify bot added the queued label Dec 29, 2025
@mergify mergify bot merged commit 638b546 into main Dec 29, 2025
35 checks passed
@mergify mergify bot deleted the huijbers/underscore-args branch December 29, 2025 19:51
@mergify
Copy link
Contributor

mergify bot commented Dec 29, 2025

Merge Queue Status

✅ The pull request has been merged at 4b57963

This pull request spent 6 seconds in the queue, with no time running CI.
The checks were run in-place.

Required conditions to merge
  • #approved-reviews-by >= 1 [🛡 GitHub branch protection]
  • #changes-requested-reviews-by = 0 [🛡 GitHub branch protection]
  • status-success=Integration test (jsii-pacmak)
  • status-success=Unit Tests
  • any of [🛡 GitHub branch protection]:
    • check-success = Integration test (jsii-pacmak)
    • check-neutral = Integration test (jsii-pacmak)
    • check-skipped = Integration test (jsii-pacmak)
  • any of [🛡 GitHub branch protection]:
    • check-success = Build
    • check-neutral = Build
    • check-skipped = Build
  • any of [🛡 GitHub branch protection]:
    • check-success = Unit Tests
    • check-neutral = Unit Tests
    • check-skipped = Unit Tests

@mergify mergify bot removed pr/ready-to-merge This PR is ready to be merged. queued labels Dec 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contribution/core This is a PR that came from AWS.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants