[ruby-core:95705] [Ruby master Feature#16296] Alternative behavior for `...` in method body if `...` is not in method definition

[ruby-core:95705] [Ruby master Feature#16296] Alternative behavior for `...` in method body if `...` is not in method definition

[daniel]

Issue #16296 has been reported by Dan0042 (Daniel DeLorme).

----------------------------------------
Feature #16296: Alternative behavior for `...` in method body if `...` is not in method definition
https://bugs.ruby-lang.org/issues/16296

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
In #16253 we settled on a syntax where the remainder arguments captured via `...` in the method definition can be forwarded via `...` in the method body. I think that was the correct decision.

But I can't forget about the use case [presented by zverok](https://bugs.ruby-lang.org/issues/16253#note-6) (and in #15049) where the method definition is used to specify mandatory and default parameters and then forward all of them to another method. I've also experienced that same use case in my code. Using the current syntax we would need to do this:

```ruby
def get(path:, accept: :json, headers: {}, ...)
  _request(method: :get, path: path, accept: accept, headers: headers, ...)
end

def post(path:, body:, accept: :json, headers: {}, ...)
  _request(method: :post, path: path, body: body, accept: accept, headers: headers, ...)
end
```

Which feels pointlessly repetitive to me. So I was thinking that maybe if `...` is not present in the method definition, then in the method body `...` could take on the meaning of "all arguments of the method". Then the code would look like this:

```ruby
def get(path:, accept: :json, headers: {}, **opts)
  _request(method: :get, ...)
end

def post(path:, body:, accept: :json, headers: {}, **opts)
  _request(method: :post, ...)
end
```

In those examples (no positional parameters) it would also allow `Hash[...]` or `{}.replace(...)` to get the hash of all keyword arguments.

Pro: it allows a new useful and powerful behavior
Con: some may consider it 'unclean' to change the behavior of `...` based on the method definition



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

[ruby-core:95715] [Ruby master Feature#16296] Alternative behavior for `...` in method body if `...` is not in method definition

[shevegen]

Issue #16296 has been updated by shevegen (Robert A. Heiler).


This proposal would change ... though and add a new meaning.
People then have to remember that ... can be omitted in 
definitions too.

I am not sure that this is the same use case as the prior one
where ... had to be used in both the method definition and
the method body.

Maybe I am too used to oldschool ruby, but I think that we 
are beginning to have too much special syntax in general; 
and people often like to build up on prior ideas, e. g. the
.: addition.

To me just sticking to an options hash seems so much better
compared to these alternatives ideas ;) - I understand it
is not the same as keyword arguments but it is so much
simpler too.

----------------------------------------
Feature #16296: Alternative behavior for `...` in method body if `...` is not in method definition
https://bugs.ruby-lang.org/issues/16296#change-82501

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
In #16253 we settled on a syntax where the remainder arguments captured via `...` in the method definition can be forwarded via `...` in the method body. I think that was the correct decision.

But I can't forget about the use case [presented by zverok](https://bugs.ruby-lang.org/issues/16253#note-6) (and in #15049) where the method definition is used to specify mandatory and default parameters and then forward all of them to another method. I've also experienced that same use case in my code. Using the current syntax we would need to do this:

```ruby
def get(path:, accept: :json, headers: {}, ...)
  _request(method: :get, path: path, accept: accept, headers: headers, ...)
end

def post(path:, body:, accept: :json, headers: {}, ...)
  _request(method: :post, path: path, body: body, accept: accept, headers: headers, ...)
end
```

Which feels pointlessly repetitive to me. So I was thinking that maybe if `...` is not present in the method definition, then in the method body `...` could take on the meaning of "all arguments of the method". Then the code would look like this:

```ruby
def get(path:, accept: :json, headers: {}, **opts)
  _request(method: :get, ...)
end

def post(path:, body:, accept: :json, headers: {}, **opts)
  _request(method: :post, ...)
end
```

In those examples (no positional parameters) it would also allow `Hash[...]` or `{}.replace(...)` to get the hash of all keyword arguments.

Pro: it allows a new useful and powerful behavior
Con: some may consider it 'unclean' to change the behavior of `...` based on the method definition



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

[ruby-core:95772] [Ruby master Feature#16296] Alternative behavior for `...` in method body if `...` is not in method definition

[eregontp]

Issue #16296 has been updated by Eregon (Benoit Daloze).


On current master `def m(a, ...); end` is a syntax error.
So I think we need to confirm first whether we will allow any other parameter alongside `...`.

----------------------------------------
Feature #16296: Alternative behavior for `...` in method body if `...` is not in method definition
https://bugs.ruby-lang.org/issues/16296#change-82591

* Author: Dan0042 (Daniel DeLorme)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
In #16253 we settled on a syntax where the remainder arguments captured via `...` in the method definition can be forwarded via `...` in the method body. I think that was the correct decision.

But I can't forget about the use case [presented by zverok](https://bugs.ruby-lang.org/issues/16253#note-6) (and in #15049) where the method definition is used to specify mandatory and default parameters and then forward all of them to another method. I've also experienced that same use case in my code. Using the current syntax we would need to do this:

```ruby
def get(path:, accept: :json, headers: {}, ...)
  _request(method: :get, path: path, accept: accept, headers: headers, ...)
end

def post(path:, body:, accept: :json, headers: {}, ...)
  _request(method: :post, path: path, body: body, accept: accept, headers: headers, ...)
end
```

Which feels pointlessly repetitive to me. So I was thinking that maybe if `...` is not present in the method definition, then in the method body `...` could take on the meaning of "all arguments of the method". Then the code would look like this:

```ruby
def get(path:, accept: :json, headers: {}, **opts)
  _request(method: :get, ...)
end

def post(path:, body:, accept: :json, headers: {}, **opts)
  _request(method: :post, ...)
end
```

In those examples (no positional parameters) it would also allow `Hash[...]` or `{}.replace(...)` to get the hash of all keyword arguments.

Pro: it allows a new useful and powerful behavior
Con: some may consider it 'unclean' to change the behavior of `...` based on the method definition



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