A reasonable optimizing compiler will produce the same machine code regardless of whether the variable is defined before the if-check or after it. Initializing local variables has no effects visible to callers so the compiler may freely reorder the code as it sees fit.

The reason is just style and clarity. First of all, it's common to add preconditions to the start of a function. If there are no items, we already know the answer and we can return right away. Second, it's generally a good idea to keep the scope of variables as small as possible.

Of course, in such a short function it doesn't really matter, but if a long function defines variable in the very beginning and uses it a lot later, can you be sure that there are no uses between? You have to carefully read through the whole function to check if there are other references.

Quickselect has O(n**2) in the worst case though. Just iterating over the list and setting the two biggest like in my solution would be optimal in runtime

Please, someone explain what means this "x" at the beginning

Top.

Your filterS results in StackOverflowError for Streams with rare satisfying elements, e.g. in

for (int i : Stream.fromS(1).filterS(x -> x % 10000 == 0).get().takeS(5))
	System.out.println(i + " : " + (i % 10000 == 0));

Nice primeS(), although somewhat slow. Try, for example, this:

Stream<Integer> ps = primeS();
for (int i = 1; i <= 10000; i++) {
	System.out.format("%5d) %6d%n", i, ps.headS());
	ps = ps.next();
}

This is awesome! My solution is O(n) too but yours is abolutely concise and elegant!

I wanted to give this a point as both a best practice as well as clever, but I guess the two are mutually exclusive.

the \w includes numbers letters and underscores so no it will think numbers are letters too and even abreviate numbers! 999999 abbreviates to 949! it will also mistakenly take words separated with underscore as being one word.

Does anyone knows how to print the string? to get the log in codewars dart console.
I tried print('mystring'); and it doesn't work.

Will it consider numbers?

Yes, that's correct and certainly a bug. In extreme cases it might even turn a terminating computation into non-terminating. Annoying n-plus-a-half loop strikes again. Easy to fix, but turns the code into a mess anyway. :)

Great solution!

But I think, it has one sneaky problem.
Your takeS will actually compute one more element than needed. This might be a problem, i.e. if the stream is exausted.