It only makes sense if you're already familar with the syntax hack it supports, which isn't even in common usage! Hello maintainance nightmare.

In the code I've been dealing with it seems to be about a 50/50 split between those who do or don't use the idiom. Possibly the codebases I've been dealing with are biased but in my experience the idiom is in fairly common usage.

What happens if result() fails? Nothing! Maybe you get a warning, but you certainly don't get an error. It's much, much better if mutators croak() if they can't perform their duty. Then error checking is entirely optional, yet still available via eval{}.

While I feel that tye's proposal is a little too clever for it's own good - you would get an error if the method failed.

The method would return an error object on failure. This error object would not get evaluted in a boolean context. On GC the DESTROY method would then croak.

While it's not a strategy I'd use (sorry tye - not convinced ;-) you would get an error.

If you use an exception throwing style of error handling then it's not a problem at all.