@jeremyevans0 Nice one, thanks for the hint! I'll add this to a `ProviderError` and inherit from there. I guess this use case is too specific to add this `self.&` to `StandardError` or even `Exception` upstream? svoop (Sven Schwyn)
The introduction of `Exception#cause` helps a lot when debugging nested errors. Same goes for wrapped errors. I'm not really sure whether such wrapped errors are an advisable pattern to begin with, feel free to comment on this, but I'...svoop (Sven Schwyn)
@byroot You're right of course, I'm so tuned in to keyword arguments. :-) Can be done in Ruby as `def respond_to?(*args)`, but you'd have to check the last args member for type. It might be more ore less ugly in C, I honestly know zilch ...svoop (Sven Schwyn)
@byroot You're right, breaking backward compatibility of the signature is out of the question. Not sure for C, but in plain Ruby, it's not a problem: ```ruby def just_checkin(*methods, include_all: false) puts methods.inspect, inc...svoop (Sven Schwyn)
Fair point, but I don't think `respond_to_any?` is a real use case given `respond_to?` is mostly used to check whether an object implements the necessary interface: The information "it implements method1 OR method2" has little practical ...svoop (Sven Schwyn)
Not sure whether this is a good idea at all, but I guess it doesn't hurt to put it up for debate. The preferred way to check e.g. whether an argument is acceptable is by use of `respond_to?`: ```ruby # Don't def notify(recipien...svoop (Sven Schwyn)
In a gem, I create a bunch of initializer shortcuts as follows: # Shortcut initializers CLASSES.each do |element, class_name| define_singleton_method(element) do |*args, **kwargs| class_name.to_class.new(*args...svoop (Sven Schwyn)
The absence pattern `(?~pat)` available since Ruby 2.4.1 is [not yet documented on `Regexp`](https://git.ruby-lang.org/ruby.git/tree/doc/regexp.rdoc) as of today. (Found it by coincidence reading [this article by Peter Cooper](https:...svoop (Sven Schwyn)