Feb. 3, 2012
10:08 p.m.
btw, i doubt that there's code which relying on destructive behavior of that prim. because in order to use such "destructive behavior" for own benefit it requires a bit of thought effort :) if you need such "erasing" (can't even find a proper term for it) replacement, then it is more natural that developer will write it by hand, instead of using a primitive with elusive (and perhaps unintended) behavior. from other side, making a new prim is better, because then image-side can do a workarounds if it not there. and i think we don't even need to implement that prim twice. what we can do is to fix the implementation of old one and then put it in additional slot of primitiveTable. -- Best regards, Igor Stasenko.