Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default Configuration#strict_keyword_argument_matching to true in Ruby >= v3.0 #697

Closed
floehopper opened this issue Dec 8, 2024 · 0 comments · Fixed by #718
Closed

Default Configuration#strict_keyword_argument_matching to true in Ruby >= v3.0 #697

floehopper opened this issue Dec 8, 2024 · 0 comments · Fixed by #718

Comments

@floehopper
Copy link
Member

floehopper commented Dec 8, 2024

From the docs:

When this option is set to false a positional Hash and a set of keyword arguments are treated the same during comparison, which can lead to misleading passing tests in Ruby >= v3.0 (see examples below). However, a deprecation warning will be displayed if a positional Hash matches a set of keyword arguments or vice versa. This is because #strict_keyword_argument_matching= will default to true in the future.

When strict matching is disabled, deprecation warnings are already displayed when a test would fail if strict matching was enabled. So there's no need to add a specific deprecation warning before changing the configuration default, because the user could simply manually disable strict matching to prevent their tests from failing.

@floehopper floehopper changed the title Consider making Configuration#strict_keyword_argument_matching true by default in Ruby >= v3.0 Consider defaulting Configuration#strict_keyword_argument_matching to true in Ruby >= v3.0 Dec 8, 2024
@floehopper floehopper changed the title Consider defaulting Configuration#strict_keyword_argument_matching to true in Ruby >= v3.0 Default Configuration#strict_keyword_argument_matching to true in Ruby >= v3.0 Dec 8, 2024
floehopper added a commit that referenced this issue Jan 1, 2025
This changes the value of
`Configuration#strict_keyword_argument_matching?` depending on the Ruby
version. The default value will continue to be `false` in Ruby v2.7, but
it will now be `true` in Ruby >= v3.0. This configuration option is not
supported in Ruby < v2.7.

The whole purpose of this configuration option was to allow gradual
adaptation to strict keyword argument, i.e. playing a similar role as
Ruby v2.7 which was designed to allow developers to prepare for the
changes to keyword arguments in Ruby v3.0.

Previously the Mocha docs alluded to this by saying things like:

    This is because {#strict_keyword_argument_matching=} will default
    to +true+ in the future.

When strict matching is disabled, deprecation warnings are already
displayed when a test would fail if strict matching was enabled. So
there's no need to add a specific deprecation warning before changing
the configuration default, because the user could simply manually
disable strict matching to prevent their tests from failing.

Closes #697.
floehopper added a commit that referenced this issue Jan 1, 2025
This changes the value of
`Configuration#strict_keyword_argument_matching?` depending on the Ruby
version. The default value will continue to be `false` in Ruby v2.7, but
it will now be `true` in Ruby >= v3.0. This configuration option is not
supported in Ruby < v2.7.

The whole purpose of this configuration option was to allow gradual
adaptation to strict keyword argument, i.e. playing a similar role as
Ruby v2.7 which was designed to allow developers to prepare for the
changes to keyword arguments in Ruby v3.0.

Previously the Mocha docs alluded to this by saying things like:

    This is because {#strict_keyword_argument_matching=} will default
    to +true+ in the future.

When strict matching is disabled, deprecation warnings are already
displayed when a test would fail if strict matching was enabled. So
there's no need to add a specific deprecation warning before changing
the configuration default, because the user could simply manually
disable strict matching to prevent their tests from failing.

Closes #697.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant