> >I'm not either. They feel like they should be operators.
> >But I don't like the thought of going in and out of a lot of generic
> >routines for
> >
> >$a = 3;
> >$a += 2;
> >
> >when the integer scalar ought to know what the inside of another integer
> >scalar looks like, and that 2 + 3 doesn't overflow.
>
> That particular case would get caught by the optimizer (I'd hope) so it'd
> not be an issue anyway.
>
> >Hmm. += isn't another opcode
> >it's a special case of a = b + c where the PMCs for a and b are the same
> >thing. And I see no real reason why it can't be part of the + entry.
>
> Whether a special case in the code would get a speedup or not's up in the
> air. (Is the test and branch faster than a generic doing it routine?) I'd
> want to test that and see before I decided.
Are we all clear then, that in perl 6, since the opcodes etc are no longer
allowed to rummage around in the internals of a PMC, its purely a question
of whether $a += 3 invokes
add($a,$a,3)
or
eqadd($a,3)
and whether $a++ invokes
add($a,$a,1)
or
postinc($a)
etc?
And that this decision is mainly a 'time it and see' decision?
