[#118180] [Ruby master Bug#20525] Percent string literal with indentation support — "bradgessler (Brad Gessler) via ruby-core" <ruby-core@...>

Issue #20525 has been reported by bradgessler (Brad Gessler).

8 messages 2024/06/04

[#118243] [Ruby master Feature#20564] Switch default parser to Prism — "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>

Issue #20564 has been reported by kddnewton (Kevin Newton).

11 messages 2024/06/07

[#118269] [Ruby master Bug#20570] Nokey behavior changed since 3.3. — "ksss (Yuki Kurihara) via ruby-core" <ruby-core@...>

Issue #20570 has been reported by ksss (Yuki Kurihara).

8 messages 2024/06/10

[#118279] [Ruby master Bug#20573] Warning.warn shouldn't be called for disabled warnings — "tenderlovemaking (Aaron Patterson) via ruby-core" <ruby-core@...>

Issue #20573 has been reported by tenderlovemaking (Aaron Patterson).

10 messages 2024/06/10

[#118281] [Ruby master Misc#20574] DevMeeting-2024-07-11 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #20574 has been reported by mame (Yusuke Endoh).

12 messages 2024/06/11

[#118346] [Ruby master Bug#20586] Some filesystem calls in dir.c are missing error handling and can return incorrect results if interrupted — "ivoanjo (Ivo Anjo) via ruby-core" <ruby-core@...>

Issue #20586 has been reported by ivoanjo (Ivo Anjo).

13 messages 2024/06/19

[#118347] [Ruby master Bug#20587] dir.c calls blocking system calls while holding the GVL — "ivoanjo (Ivo Anjo) via ruby-core" <ruby-core@...>

Issue #20587 has been reported by ivoanjo (Ivo Anjo).

7 messages 2024/06/19

[#118360] [Ruby master Bug#20588] RangeError: integer 132186463059104 too big to convert to 'int' since cdf33ed5f37f9649c482c3ba1d245f0d80ac01ce with YJIT enabled — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

Issue #20588 has been reported by yahonda (Yasuo Honda).

10 messages 2024/06/20

[#118388] [Ruby master Feature#20594] A new String method to append bytes while preserving encoding — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

SXNzdWUgIzIwNTk0IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJ5cm9vdCAoSmVhbiBCb3Vzc2llciku

32 messages 2024/06/25

[ruby-core:118393] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil`

From: "ufuk (Ufuk Kayserilioglu) via ruby-core" <ruby-core@...>
Date: 2024-06-26 21:54:11 UTC
List: ruby-core #118393
Issue #19979 has been updated by ufuk (Ufuk Kayserilioglu).


The result of the discussion at the face to face dev meeting in Naha was that while #15554 is preferred, it has some drawbacks and an explicit method for declaring that a method accepts no blocks is still a good thing to have. 

For that reason, I've gone ahead with implementing this feature (based on the original work done by @nobu, thank you!) and exposed a `&nil` declaration through `{Method,UnboundMethod,Proc}#parameters` as `[[:noblock]]`: https://github.com/ruby/ruby/pull/11065

----------------------------------------
Feature #19979: Allow methods to declare that they don't accept a block via `&nil`
https://bugs.ruby-lang.org/issues/19979#change-108908

* Author: ufuk (Ufuk Kayserilioglu)
* Status: Open
----------------------------------------
## Abstract

This feature proposes new syntax to allow methods to explicitly declare that they don't accept blocks, and makes passing of a block to such methods an error.

## Background

In #15554, it was proposed to automatically detect methods that do not use the block passed to them, and to error if a block was passed to such methods. As far as I can tell, it was later on closed since #10499 solved a large part of the problem.

That proposal has, as part of [a dev meeting discussion](https://github.com/ruby/dev-meeting-log/blob/b4357853c03dfe71b6eab320d5642d463854f50f/2019/DevMeeting-2019-01-10.md?plain=1#L110-L120), a proposal from @matz to allow methods to use `&nil` to explicitly declare that they don't accept a block. At the time, the proposal was trying to solve a bigger problem, so this sub-proposal was never considered seriously. However, notes in the proposal say:
> It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations)

This proposal extracts that sub-proposal to make this a new language feature.

## Proposal

In Ruby, it is always valid for the caller to pass a block to a method call, even if the callee is not expecting a block to be passed. This leads to subtle user errors, where the author of some code assumes a method call uses a block, but the block passed to the method call is silently ignored.

The proposal is to introduce `&nil` at method declaration sites to mean "This method does not accept a block". This is symmetric to the ability to pass `&nil` at call sites to mean "I am not passing a block to this method call", which is sometimes useful when making `super` calls (since blocks are always implicitly passed).

Explicitly, the proposal is to make the following behaviour be a part of Ruby:
```ruby
def find(item = nil, &nil)
  # some implementation that doesn't call `yield` or `block_given?`
end

find { |i| i == 42 }
# => ArgumentError: passing block to the method `find' that does not accept a block.
```

## Implementation

I assume the implementation would be a grammar change to make `&nil` valid at method declaration sites, as well as raising an `ArgumentError` for methods that are called with a block but are declared with `&nil`.

## Evaluation

Since I don't have an implementation, I can't make a proper evaluation of the feature proposal. However, I would expect the language changes to be minimal with no runtime costs for methods that don't use the `&nil` syntax.

## Discussion

This proposal has much smaller scope than #15554 so that the Ruby language can start giving library authors the ability to explicitly mark their methods as not accepting a block. This is fully backward compatible, since it is an opt-in behaviour and not an opt-out one.

Future directions after this feature proposal could be a way to signal to the VM that any method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly declared a block parameter should be treated as not accepting a block. This can be done via some kind of pragma similar to `frozen_string_literal`, or through other means. However, such future directions are beyond the scope of this proposal.

## Summary

Adding the ability for methods to declare that they don't accept a block will make writing code against such methods safer and more resilient, and will prevent silently ignored behaviour that is often hard to catch or troubleshoot.



-- 
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/lists/ruby-core.ml.ruby-lang.org/

In This Thread