Elia Schito

If I understood correctly they're compiled down to regular regexp in most cases, so it shouldn't be an issue, otherwise I agree on making it optional.

@hmdne I agree 100% on the release plan toward the updated behavior. About how to implement them, I thought for a long time that Ruby could benefit from a Symbol...

oh, I see, so it's able to eliminate nested calls, that's a good point. Sounds like we can do the same here but maybe we can cap the number of...

Ok, this is interesting and probably worth reporting as Ruby bug: ``` opal:master ⤑ ruby -ve 'def foo(x); p x; end; foo(**{})' ~/C/opal ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17] Traceback...

Not sure they reached a conclusion tho, preview2 still looks undecided about the best behavior (but adds a warning): ``` ⤑ rvm 2.6 ~ Using /Users/elia/.rvm/gems/ruby-2.6.0-preview2 ⤑ ruby -ve 'def...

@eregon this issue seems just about this case and far from settled https://bugs.ruby-lang.org/issues/15078 I'll keep the current Opal behavior and this issue open until a decision is made.

We tried that, the issue seems to be with being able to pass an arbitrary number of arguments as you can't use "apply" with "new"

Actually I don't remember if we tried this: http://www.bennadel.com/blog/2291-invoking-a-native-javascript-constructor-using-call-or-apply.htm :grin:

`Reflect.construct` also looks like a great option https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Reflect/construct

just for info here's the relevant code: https://github.com/opal/opal/blob/master/lib/opal/nodes/literal.rb#L121-L147 Apparently it doesn't call `.$to_s()` explicitly but rather relies of JS calling `.toString()` [wich in turn calls `.$to_s()`](https://github.com/opal/opal/blob/master/opal/corelib/runtime.js#L1828-L1830) So, maybe we can...