From: "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>
Date: 2023-08-09T15:49:02+00:00
Subject: [ruby-core:114378] [Ruby master Feature#19832] Method#destructive?, UnboundMethod#destructive?

Issue #19832 has been updated by Dan0042 (Daniel DeLorme).


kddnewton (Kevin Newton) wrote in #note-16:
> I don't understand how you would go about statically detecting instance variable mutations.

Actually I'm starting to think this is doable. If we restrict ourselves to methods invoked on `self` only, and we compute at the time the #destructive? method is called (so it's not statically at load time), it should be possible to figure out which methods are destructive based on the inheritance graph at that time, and propagate the 'destructive' flag to the calling method. So if a method calls `instance_variable_set` or `self.instance_variable_set` we can find out if we're calling the original destructive method or an overridden version. For Method#destructive? we can even take into account singleton methods. If the method calls via `x=self; x.instance_variable_set` or `send(:instance_variable_set)` then it's not possible, but that's a limitation I could live with.


----------------------------------------
Feature #19832: Method#destructive?, UnboundMethod#destructive?
https://bugs.ruby-lang.org/issues/19832#change-104124

* Author: sawa (Tsuyoshi Sawada)
* Status: Open
* Priority: Normal
----------------------------------------
I propose to add `destructive?` property to `Method` and `UnboundMethod` instances, which shall behave like:

```ruby
String.instance_method(:<<).destructive? # => true
String.instance_method(:+).destructive? # => false
```

One main purpose of using these classes is to inspect and make sure how a certain method behaves. Besides arity and owner, whether a method is destructive or not is one important piece of information, but currently, you cannot achieve that from `Method` or `UnboundMethod` instances.

The problem is how to implement this. It is best if this information (whether or not a method is destructive) can be extracted automatically from the method definition.

Unlike owner and arity, it may or may not be straightforward by statically analyzing the code. I think that, if a method definition defined at the ruby level does not call a destructive method anywhere within its own definition, and no dynamic method calls (`send`, `eval`, etc.) are made, then we can say that the method is non-destructive. If it does call, then the method is most likely a destructive method (it would not be destructive if the internally-called destructive method is applied to a different object. Or, we could rather call that a destructive method in the sense that it has a destructive side effect).

If doing that turns out to be difficult for some or all cases, then a practical approach for the difficult cases is to label the methods as destructive or not, manually. We can perhaps have methods `Module#destructive` and `Module#non_destructive` which take (a) symbol/string argument(s) and return the method name(s) in symbol so that they can be used like:

```ruby
class A
  destructive private def some_destructive_private_method
    ...
  end
end
```

or

```ruby
class A
  def foo; ... end
  def bar; ... end
  def baz; ... end

  non_destructive :foo, :baz
  destructive :bar
end
```

or

```ruby
class A
  non_destructive

  def foo; ... end
  def baz; ... end

  destructive

  def bar; ... end
end
```

When the method is not (yet) specified whether destructive or not, the return value can be `"unknown"` (or `:unknown` or `nil`) by default.

```ruby
String.instance_method(:<<).destructive? # => "unknown"
```




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/