I think the message is that trying to design an API which does something different depending on whether the input is iterable (callable etc) is the wrong way to go about it. Eg an imaginary
function do_stuff(thing)
if is_iterable(thing)
collect(thing)
elseif is_callable(thing)
thing()
else
fallback(thing)
end
end
can be a very confusing design, regardless of whether it is done with traits or not.
Technically a trait for something supporting the iterate
protocol would be very easy to add to the language, but I suspect that one of the reasons this has not happened is that usually there is a better way to organize code.