Sam S. via RT wrote: >Can you describe an actual example of something a Perl 6 module author >might want to do that could cause IteratorEnd to be leaked outside of >its intended context?
Introspect on the CORE:: stash. Perhaps in order to parse code that refers to objects by their Perl 6 names, and which makes use of the public iterator API including the approved "=:= IteratorEnd" check. >It never reaches the "outside world", as long as implementers follow >this protocol. So, say, putting the object into a public namespace is an unapproved use, and has to be unapproved because it would cause such a leak. Oops, the core implementation is breaking the protocol. Better remove CORE::<IterationEnd>. >If the documentation does not sufficiently deter people from trying this, >then maybe this should be a p6doc ticket instead. If you want to maintain the situation of IterationEnd being reified as a named object, but not able to be processed by the language's general mechanisms, then the documentation certainly needs to prohibit more than just direct, deliberate references to it. Prohibit name lookups from stashes? Prohibit metaprogramming of iterator code? It's not at all obvious which things are intended to be unsupported. >So if you want to litter other parts of Perl 6 with (potentially >performance-degrading) checks for the sentinel value The checks are not free, of course, but they're cheap. As jnthn has explained, you're using a sentinel-delimited API specifically because that identity comparison is cheap. -zefram
