You can anchor that regex to the start of the string with ^ and have it fail faster; in practice I haven't been able to measure a difference, so either perl is clever enough, or the whole thing is determined by IO performance.

I wouldn't do this as an "anded if" but in a loop with an array of vowels. As soon as the script has found the first vowel the script would continue with the next vowel but if the vowel wasn't found it would stop the whole search as it's not interesting whether the other vowels are in the string.

The performance of my solution depends on the distribution of the strings. Statistically I'm too weak to tell you what is faster. The longer your strings are the worse is my solution. If your search contains a lot of strings and there are some with a length less than number of vowels you could skip the whole test as in a less-than-five(six)-letter-string there is evidently no chance for five(six) different vowels.

I wouldn't do this as an "anded if" but in a loop with an array of vowels. As soon as the script has found the first vowel the script would continue with the next vowel but if the vowel wasn't found it would stop the whole search as it's not interesting whether the other vowels are in the string.

Uhm, in which way does an "anded if" continue with a next vowel after a previous vowel wasn't found?

So, what code did the discussion between you Perl developers produce? What advantages are there to it? What disadvantages? If you are developers, you will surely have written code. If none of you developers has an idea, it surprises me that none of you developers has a question about perlre.

Just as a cautionary side-note, the character set [a,e,i,o,u] (which is what I assume was originally posted without awareness of the effect of square brackets) includes ',' (comma) as a vowel! Please see Markup in the Monastery and Writeup Formatting Tips.

Since you have 5 independent, overlapping searches you wish to perform simultaneously, you necessarily need something that won't consume letters on matching (assuming you don't want to use embedded code to cache results in a hash). Variable width match without consuming == look-ahead, so I'd start looking there. Looking ahead and looking behind.

That would not be my guess, unless it's the /i that's killing the performance. /a/ will not use the regexp engine, the optimizer will do it. If speed is an issue, and you want to be case sensitive, my bet would go to:

but I'm too lazy to come up with a good benchmark (which should test for both match and non-match). And if the query set would be English words, I'd order the vowels from least frequently occurring to most frequently (probably u-i-o-a-e, but I'd have to look that up), in order to fail faster.

They may be complicated, but at least they are "solutions". What part of "verify that a string has all 5 vowels" didn't you understand, or do you expect that half a solution plus a human pass over the output data for the other half is appropriate?

hbm gets +1 for noticing a small bug that I missed. You get -1 for being anal about my methodology. My code is easily adapted by anyone with half a brain and it's not our job to provide exact homework-quality solutions if we don't feel like it. I'm sure you'll downvote this but I really don't care, considering that ww downvoted me just the other day for providing a solution that was "too" good. If I'm going to get downvoted by one of you no matter what I do, then that leaves me pretty much free to do whatever I want - it won't make any difference to my rating.