Documentation does not mention that {float} also matches {int} and supports scientific notation

[twometresteve]

👓 What did you see?

    When I print the type of 1                                             # features/test.feature:3
      Ambiguous match of "I print the type of 1":

      steps/scripting_steps.rb:1:in `nil'
      steps/scripting_steps.rb:5:in `nil'

      You can run again with --guess to make Cucumber be more smart about it
       (Cucumber::Ambiguous)
      features/test.feature:3:in `I print the type of 1'

✅ What did you expect to see?

Because there is no decimal point on the number provided, Cucumber should use the {int} step definition.

  Scenario: Demonstrate that floats and ints are not handled as documented # features/test.feature:2
1 is an int
    When I print the type of 1                                             # steps/scripting_steps.rb:1

📦 Which tool/library version are you using?

ruby-cucumber v10.0 (earlier versions also behave the same).
Ruby v3.2.3 (and others)

🔬 How could we reproduce it?

1. gem install cucumber
2. Contents of features/test.feature:

Feature: Ambiguous parameter
  Scenario: Demonstrate that floats and int params are not handled as documented
    When I print the type of 1

3. Contents of steps/steps.rb:

When('I print the type of {int}') do |number|
  puts "#{number} is an int"
end

When('I print the type of {float}') do |number|
  puts "#{number} is a float"
end

4. Run the command cucumber -r steps

📚 Any additional context?

This behaviour seems at odds with the cucumber-expressions documentation:

[luke-hill]

Is this broken in earlier versions of cucumber. I'm only interested in versions around v6/7 and onwards?

This feels like a very "edge" case scenario.

I can't remember the capture type for float but if it matches integers as well, that is where your problem lies.

[luke-hill]

I've messaged the wider team about this. I've managed to trace some really old commits that are 5/6 years old when we first introduced expressions. I have a feeling this might be contentious.

[mpkorstanje]

@twometresteve we introduced this intentionally because of cucumber/common#600. And looking at bugsnag/maze-runner#773 I see that you could get by with using floats so it seems that you are following the expected usecase. Other than this being a change to your project, is there a reason you would need non-decimal numbers to match integers exclusively?

[twometresteve]

Hi @luke-hill and @mpkorstanje - many thanks for your comments. I've only just thought to come and check up on the issue as my email filter for Github has turned out to be too aggressive. 🤦

Thanks for confirming it's an intentional change - that's not problem for me, I'll just use floats.

[mpkorstanje]

Cheers! Then I think we can suffice with a doc update.