Ruby protobuf repeated fields local jumperror on each without block

[fables-tales]

What version of protobuf and what language are you using? Version: 3.6.0 Language: Ruby

What operating system (Linux, Windows, ...) and version? OS X 10.14

What runtime / compiler are you using (e.g., python version or gcc version) Ruby 2.5, also applies to Ruby 2.3 and 2.6.

What did you do?

require 'google/protobuf'

Google::Protobuf::DescriptorPool.generated_pool.build do
  add_message "google.example.ExampleProto" do
    repeated :things, :string, 1
  end
end

module Google
  module Example
    ExampleProto = Google::Protobuf::DescriptorPool.generated_pool.lookup("google.example.ExampleProto").msgclass
  end
end

a = [1,2,3]
a.each.with_index { |item, index| puts(item, index) }

proto = Google::Example::ExampleProto.new
proto.things << "a"
proto.things << "b"
proto.things << "c"

#explodes, because each requires a block even while chaining
proto.things.each.with_index { |item, index| puts(item, index) }

What did you expect to see No error should be produced, instead values from the repeated field should be printed with their index.

What did you see instead?

Traceback (most recent call last):
	1: from hi_pb.rb:24:in `<main>'
hi_pb.rb:24:in `each': no block given (LocalJumpError)

A local jump error should not be produced on each with no block, instead returning an enumerator.

>> [1,2,3].each
=> #<Enumerator: [1, 2, 3]:each>

Anything else we should know about your project / environment

[TeBoring]

We currently haven't supported this use case. Would you mind send PR to us?

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.