Sam S. via RT wrote: >is there anything else other than the `CORE::` object that would leak an >`IterationEnd` value into a Seq/List passed to user code?
There are some kinds of programming that would be liable to innocently run into the actual object even if it doesn't have a regular name. It looks like Perl 6 broadly intends to enable the affected kinds of programming, but this is where my Perl 6 knowledge runs out: I don't know which specifically exist now or how to do them. Still, I think the prospects are worrying enough even where Perl 6 doesn't actually do them yet. First, there's MOP stuff, where metaclass code might wrap method calls or otherwise tweak their implementation. This kind of code would naturally need to handle all the kinds of value that can be passed to or returned from a method. So it can see the IterationEnd value in the operation of valid iterator code, without specifically knowing that it's dealing with iterator code. In a related vein, think about introspection into the call records of a running program. For example, one might want to produce a stack trace that shows the arguments to each call, as does Perl 5's Carp::confess(). Or one might run a program under a Perl 6 debugger, trying to emit trace data for each call and return. One can also consider introspection into the non-running code reified in Sub objects and the like, or plugging extensions into the compiler. Where the code has a "=:= IterationEnd" operation, the introspection would be liable to see the IterationEnd value, even if it wasn't spelled with a regular name. Reformulating "$a =:= IterationEnd" as "is_IterationEnd($a)" could avoid this problem for the comparisons, but it still arises for code that returns the sentinel. -zefram
