Well, my view on context is that its a wonderul thing that is easily inappropriately used. I'd guess that I use it in less than 10% of the subroutines I write, but when it makes sense I dont hesitate at all. Used sparingly, only when it makes semantic sense, I feel it reduces the chance for errors.

As for artistry, I think I may not have been quite as clear as I wanted to. I didnt mean to imply the aristry of Perl, but rather artistry of programming. Designing an intuitive, flexible powerful, extensible interface to a body of code IMO requires an artistic touch. Without the art the interface quickly becomes annoying, frustrating, and counterintuitive. An example for instance is accessors in Perl. Do you do them as lvalue subs (I probably wouldn't), seperate gets and sets ala Java, VB etc? (nope blech), single get/set accessors that return the old value (occasionally but not often) or ones that return $self on set? (my preference.) These are artistic decisions. Theres no science involved. They are all functionally equivelent, but from an aesthetic side (look and feel) they are very different. How many times have you used a crappy API and thought to yourself "this API is soooo clunky", im betting lots just like me. I would argue that the clunky API is the product of an unartistic programmer, and a little bit of art would have improved matters greatly.

Anyway, from the artistic point of view you might consider wantarray to be like neon lime green/yellow. Not a lot of paintings would benefit from the color, but its not like you are going to just throw away the tube of paint: one day itll be just the right shade...

YMMV and apparently does. But I'm someone who is bugged by the feeling of solving artificially imposed problems, and I've come to feel that context is one of those. :-(

To me context is like the invisible argument. If it were to be removed then we would probably end up requiring a flag in the parameters, or worse duplicate subroutines, to do the same thing. I think that this would be worse than the occasional mishap that occurs due to context. So to me its not an artificially imposed problem, its an artifically imposed solution. ;-)

This reminds me of a comment I saw once. Some languages totally dispose of pointers (perl references). VB is an example. The argument goes that pointers are a consistent source of error so remove them entirely. The problem then becomes that for nontrivial work you need pointers. So what do you end up doing? Reinventing them. In VB this means using variant arrays and all the horrors that entails. The comment was: "Dont remove features just because they are a source of error, doing so will only require the user to hand code an equivelent, and this is likely to be even worse than the original problem." I would say this applies nicely to context. Removing it would only result in worse problems. At least with context the rules are relatively simple, but more importantly uniform for all subroutines. (I mean rules of how context works, not what a routine returns in a given context.)

A rule of thumb for context IMO is that if the effect of context doesnt make sense when the code is read aloud then it shouldnt be provided, but if it would make sense, then it should be.

Anyway, as always tilly, a thought provoking thread.