[perl #130520] [RFC] Deprecate `flatmap`

2017-01-11 Thread Zoffix Znet via RT
On Wed, 11 Jan 2017 03:03:29 -0800, sml...@gmail.com wrote: > Okay, I get it, I shouldn't have tried to be cute in how I phrased > that. Right, it's a bit weird to base your argument on a fictional survey with results you made up :) > But do you really think I'm wrong in considering each of the

[perl #130437] [RFC] Ranges with Infs on endpoints could be smarter ((0..Inf)[99999999999])

2017-01-11 Thread Zoffix Znet via RT
On Thu, 29 Dec 2016 13:49:40 -0800, sml...@gmail.com wrote: > So maybe this is more of a performance bug/oversight than an RFC? > I think all cases should give the same result that they do now. > They just should do it in O(1) instead of O(n). It's a bit more involved than that due to floating poi

Re: [perl #130437] [RFC] Ranges with Infs on endpoints could be smarter ((0..Inf)[99999999999])

2017-01-11 Thread Parrot Raiser
> "So is a weird, chunked, unpredictable, and at-times absolutely wrong result > better than correct but slow range, that at large enough values can be made > to be non-increasing, infinite, and one that hangs when you attempt to fully > reify it?" "I'm sorry, Dave, I can't do that". In some ca

[perl #130542] \c[BELL] returns the U+0007 control code not U+1F514 BELL

2017-01-11 Thread via RT
# New Ticket Created by Samantha McVey # Please include the string: [perl #130542] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130542 > Fudged test in S02-literals/char-by-name.t is "\c[BELL]", "🔔", '\c[BELL] returns 🔔, BE

[perl #130540] [BUG] || && and or cannot be "overloaded"

2017-01-11 Thread jn...@jnthn.net via RT
On Tue, 10 Jan 2017 17:59:05 -0800, c...@zoffix.com wrote: > On Tue, 10 Jan 2017 16:23:18 -0800, fernandocor...@gmail.com wrote: > > If I write another || operator it will continue to use the original > > version. > > > > https://irclog.perlgeek.de/perl6/2017-01-10#i_13895823 > >

Re: [perl #130540] [BUG] || && and or cannot be "overloaded"

2017-01-11 Thread Lloyd Fournier
There is a &infix:<&&> which might be where some confusion comes from. I guess that's there for meta operators. For example: multi sub infix:<&&>("foo","bar") { "win" }; say "foo" && "bar" # bar say Z&& # win so it does kinda work actually just not as you might expect. LL On Thu, Jan 12, 2017

Re: [perl #130535] Dynamic module loading by require in another modules has broken recently?

2017-01-11 Thread Lloyd Fournier
Confirmed. As you say, it's probably because require hasn't been updated to the new lexical importing design like "use" has. A few of the tests probably have to be re-written for require as well. LL On Wed, Jan 11, 2017 at 6:27 AM Asato Wakisaka wrote: # New Ticket Created by Asato Wakisaka # P