Issue #19194 has been reported by make_now_just (Hiroya Fujinami).
----------------------------------------
Feature #19194: Add Regexp.linear_time?
https://bugs.ruby-lang.org/issues/19194
* Author: make_now_just (Hiroya Fujinami)
* Status: Open
* Priority: Normal
----------------------------------------
I suggest adding a new method named `Regexp.linear_time?` to check if matching against a given regexp can be completed in linear time by the optimization introduced in #19104 (GitHub PR [#6486](https://github.com/ruby/ruby/pull/6486)).
This method was discussed in #19104. I'm not sure the name is best.
# Example
```
Regexp.linear_time?(/a/) # => true
Regexp.linear_time?(/(a|a)*\1/) # => false, because this uses a back-reference.
# This can accept a regexp source string and flags like `Regexp.new`.
Regexp.linear_time?('a') # => true
Regexp.linear_time?('a', Regexp::IGNORECASE) # => true
```
For example, this method is useful for implementing a Rubocop rule to check a regexp is ReDoS safe.
# Implementation
Implementation is done at GitHub PR [#6901](https://github.com/ruby/ruby/pull/6901).
See the details there.
--
https://bugs.ruby-lang.org/
Issue #19193 has been reported by YO4 (Yoshinao Muramatsu).
----------------------------------------
Feature #19193: drop DOS TEXT mode support
https://bugs.ruby-lang.org/issues/19193
* Author: YO4 (Yoshinao Muramatsu)
* Status: Open
* Priority: Normal
----------------------------------------
On Windows platform, ```File.open(path, "r")``` returns an object different from "rt" and "rb". I call that DOS TEXT mode here.
DOS TEXT mode does
* crlf conversion
* 0x1a treated EOF charactor on read
and others (see Bug #19192).
But DOS TEXT mode is almost unnecessary today and it seems to introduce lot of code complexities.
Now there is less need for dos text mode
* Microsoft's most apps works without CRLF newline.
* Creating a crlf text file today should be explicit. (but that is default mode on windows now)
* Interpreting EOF charactor can cause trouble.
I think it's time to consider dropping DOS TEXT mode.
What challenges are there and what preparation is needed?
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by Eregon (Benoit Daloze).
shugo (Shugo Maeda) wrote in #note-14:
> Speaking of implicity of blocks, `def f; g(&); end` causes a syntax error, so it may be better to allow it, or disallow `def f(...); g(&); end` in the future versions.
Since some time @ko1 worked on no implicit block if not a parameter of the method (with the exception of `yield` in the body). I think that's a good property, so I think it's good for `def f; g(&); end` to be a syntax error.
For `def f(...); g(&); end` "..." is "capture all arguments, positional, keyword and block" so I think it's more natural there to be able to access the block (although I can't think of when that would be useful, maybe `def f(...); g(&); h(...) end` when `h` is known to ignore the block but that feels hacky, better use `(*, **, &)` parameters then).
> Anyway, I've fixed the behavior of `...` as described in #note-9.
Thanks!
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100680
* Author: shugo (Shugo Maeda)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by shugo (Shugo Maeda).
mame (Yusuke Endoh) wrote in #note-12:
> I feel that only `&` is acceptable since a block is implicitly passed. But I don't think `*` and `**` make sense inside `def foo(...)`.
Speaking of implicity of blocks, `def f; g(&); end` causes a syntax error, so it may be better to allow it, or disallow `def f(...); g(&); end` in the future versions.
Anyway, I've fixed the behavior of `...` as described in #note-9.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100678
* Author: shugo (Shugo Maeda)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by mame (Yusuke Endoh).
> IMHO if ... is used then *, ** and & should all be forbidden (a SyntaxError at parse time).
I agree with this. If you want to do that, you should take it with `def foo(*, **, &)`.
I feel that only `&` is acceptable since a block is implicitly passed. But I don't think `*` and `**` make sense inside `def foo(...)`.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100630
* Author: shugo (Shugo Maeda)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by Eregon (Benoit Daloze).
shugo (Shugo Maeda) wrote in #note-8:
> `&` is allowed in 3.1, so it's a breaking change to prohibit it.
Right and `&` is not problematic re performance, it's a completely separate argument anyway.
I agree with your proposal in your comment just above this one.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100573
* Author: shugo (Shugo Maeda)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 3.2
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by shugo (Shugo Maeda).
Status changed from Closed to Open
I think it's most conservative to probhibit `*` and `**`:
```
def foo(...)
bar(&) # OK
baz(*) # error
quux(**) # error
end
```
And a error should occur in the following code instead of dropping keyword arguments:
```
def foo(*, **, &)
bar(...)
end
def bar(*args, **kw, &block)
p [args, kw, block&.call]
end
foo(1, 2, x: 3, y: 4) { 5 }
```
What do you think, Matz?
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100495
* Author: shugo (Shugo Maeda)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/
Issue #19134 has been updated by shugo (Shugo Maeda).
Eregon (Benoit Daloze) wrote in #note-5:
> IMHO if `...` is used then `*`, `**` and `&` should all be forbidden (a SyntaxError at parse time).
> Because that way is the best for optimizing delegation.
> And also taking apart `*` and `**` is arguably not really delegation anymore.
`&` is allowed in 3.1, so it's a breaking change to prohibit it.
----------------------------------------
Feature #19134: ** is not allowed in def foo(...)
https://bugs.ruby-lang.org/issues/19134#change-100493
* Author: shugo (Shugo Maeda)
* Status: Closed
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
`*` and `&` are allowed in the body of a method with `...` argument forwarding, but `**` is not allowed.
```
def foo(...)
bar(*) # OK
baz(&) # OK
quux(**) # NG
end
```
Is it intended behavior?
It seems that parse.y has code like `#ifdef RUBY3_KEYWORDS`, and if RUBY3_KEYWORDS, `**` will also be supported.
--
https://bugs.ruby-lang.org/