[ruby-core:59877] [ruby-trunk - Feature #9428] Inline argument expressions and re-assignment

Issue #9428 has been updated by Tom Wardrop.


Without syntax highlighting, it isn't super obvious, but in simple cases (which are the main use case), like `fetch(id.to_i)`, it is obvious enough without the aid of syntax highlighting. 

Remember though, while there are aspects to this that are potentially unobvious, there are other aspects which it make things more obvious, such as in the case of auto-documentation. If the transformation of #to_i or #to_sym is embedded within the method signature, it makes it obvious that the given argument must respond to that method (#to_i or #to_sym). If this logic is hidden away in the method/block body, the author must either document it explicitly, or the user must troll through the method body unless they prefer to find out the hard way at runtime.

There are certainly benefits to be had here beyond merely reducing verbosity. The trade-offs are merely readability related, but as I've said, keeping the expressions simple and good code highlighting pretty much completely mitigate that problem.

If we can't get over the argument name inferencing, then perhaps someone can suggest a syntax for defining the argument name explicitly, e.g.

    def fetch(id.to_i as id)
    end

But I don't really find that example any more readable. The implicit assignment in the original proposal makes it easy to distinguish expression arguments from arguments with default values.

I certainly don't expect anyone to see this proposal and instantly fall in love. It's a pretty radical idea.

----------------------------------------
Feature #9428: Inline argument expressions and re-assignment
https://bugs.ruby-lang.org/issues/9428#change-44434

* Author: Tom Wardrop
* Status: Open
* Priority: Normal
* Assignee: 
* Category: core
* Target version: 
----------------------------------------
Just a random idea. Currently, Ruby allows you to use any arbitrary expression for setting default values for arguments, which can be really convenient and makes for clear code, especially handy for documentation, etc. For example:

    def fetch(id, cache = config[:cache])
      # bleh
    end

In the same vein, as well as setting a default value using an arbitrary expression, it's not uncommon to *post-process* an argument, some common examples include:

    arg = arg.upcase
    arg = arg.to_sym
    arg = arg.dup

It would be rather nice in my opinion to be able to do this inline when defining the argument:

    def fetch(id.to_i, cache = config[:cache])
      # bleh
    end

This works well where the argument is the receiver of the method call, but what if you wanted to do `Integer(id)` in the above example instead of using String#to_i? There are two options. One could either fallback to processing the argument within the method/block body, or, you could make the implementation a little bit clever by using inferencing.

Ruby could auto-assign the passed argument to the first variable encountered in the expression. So in the following example, as soon as the virtual machine encounters `id`, it recognises it as a variable and assigns the argument value before continuing. When encountering subsequent variables, Ruby would take the usual action and look for a corresponding method in `self` before throwing an error. You can always disambiguate by qualifying the receiver, e.g. `self.id`

    def fetch(Integer(id), cache = config[:cache])
      # bleh
    end

Whatever the result of the expression, it's assigned as the final argument value. So in the case of `id.to_i`, the argument name of `id` is inferred. `id` is set to the supplied argument for the duration of the expression. The result of the expression is then re-assigned as the value of `id`. This technically allows expressions of arbitrary complexity, but like all things in Ruby, with great power comes great responsibility. One must use common sense when deciding whether to manipulate the argument inline, or within the method body. As long as the expression is of reasonable length and complexity, readability remains perfectly reasonable.

Interested to get some thoughts and opinions on this one. I sense the potential for controversy :)




-- 
http://bugs.ruby-lang.org/