InvictusMB

Alright, I got it working. Turns out I did not allocate the buffer to read into and it was always reading 0 records. Here's [the good stuff](https://github.com/InvictusMB/gui.cs/tree/uwp). The question now...

As far as I understand it's mostly Windows version compatibility question. These APIs are provided by specific Win10 SDK versions. If we do this change on Windows console driver itself...

I tested it again and it seems the only real culprit was `ReadConsoleInput` marshaling. The rest works fine with `kernel32.dll`. I don't know how to validate the added value of...

They do use the same library. The difference is that in `Release` mode `.NET Native tool chain` generates wrappers for P/Invoke marshaling. And in case of `ReadConsoleInput` with `InputRecord []`...

`[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 2)]` did not work either.

The UWP thing is still not clear to me as per #707. I'll give more input when I try to publish something on Windows store and see if I get...

Functionally the issue I had is fixed. I'm not sure if the artifacts built for UWP platform will satisfy the MS store requirements. I had no chance to test publishing...

So is this suggestion about dropping the whole proposal in favor of giving `::` a meaning of functional pipelining? Is `foo::bar` going to be equivalent to `_.partial(bar, foo)` ?

@Artazor `bar.call(foo, a, b, c)` doesn't fit the provided example from first post: ``` var list = items ::_.map(v => v.getName()) ::_.flatten() ::_.uniq() ``` That example implies that result of...

@Artazor I was initially as confused by this thread as you are. Therefore my original question. Nevertheless, I can envision the need for 3 different operators: * Functional pipelining (elm...