Alternatively make it @@Jit("off") only and any other argument will lead to
an error for now.
Then the problem left becomes "Jit" being a very short global class.
On Mon, Aug 3, 2020 at 10:36 PM Benas IML wrote:
> `@@NoJit` sounds pretty alright to me.
>
> On Mon, Aug 3, 2020, 11:27 PM Derick
`@@NoJit` sounds pretty alright to me.
On Mon, Aug 3, 2020, 11:27 PM Derick Rethans wrote:
> On 3 August 2020 20:20:35 BST, Benjamin Eberlei
> wrote:
>
> >In that case maybe we should rename the attribute to @@DisableJit ?
> >This
> >would not clutter the global namespace with a "jit" class.
>
On 3 August 2020 20:20:35 BST, Benjamin Eberlei wrote:
>In that case maybe we should rename the attribute to @@DisableJit ?
>This
>would not clutter the global namespace with a "jit" class.
Things with a negative name are usually a code smell. I'm not keen on a
@[disableJit] attribute name.
On Mon, 3 Aug 2020 at 19:52, Stanislav Malyshev wrote:
> I think turning JIT off is a valid use case, the rest looks much more
> iffy. I am not sure we want to let people tell the engine to JIT certain
> functions - are there a lot of cases where the engine wouldn't do it but
> it's actually the
On Mon, Aug 3, 2020 at 8:51 PM Stanislav Malyshev
wrote:
> Hi!
>
> > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> and
> > "function". This trigger mode feels like micro-management for developers
> > and since it has virtually no spotlight in discussions and blog
Hi!
> Only the trigger mode 4 (attributes) is actually using @@Jit("tracing") and
> "function". This trigger mode feels like micro-management for developers
> and since it has virtually no spotlight in discussions and blog posts about
> the JIT at the moment, we don't know if it brings benefits.
