Naming Things - Task and Subtask

[Attila Kelemen]

>
> Attila (and still Eric)
> It seems like both of you don’t like the TWR part, but I find it extremely nice to have, and a lot of times prefer it over a lambda argument.
> TWR allows us to propagate checked exceptions, which till we add union-types in generic levels is impossible to do with lambdas, and it doesn’t have the (justified) restrictions of lambdas.

I'm not really against having the TWR way available as a low level
construct, I just like to have these lambda blocks as utility to which
you resort to (although tbh, it is a bit strange that scoped values
give you lambda block only, while STS only TWR). Of course, checked
exceptions are a nightmare in these constructs, and that is why I
usually have `UnsafeFunction<T, E extends Throwable>` (and its
gazillion siblings) around (and I'm pretty sure there are many-many
people creating their own "Unsafe" function interfaces). In an idea
world we could have constructs similar to Kotlin's inline functions,
which would solve this issue (fingers crossed for it :))

>
> var results = StructuredTask.StreamBuilder()
>                                    .value<String>("USERNAME", "duke")
>                                    .flatFork(() -> Stream.of(workers))
>                                    .join()
>                                    .throwIfFailed() // "StructuredTask.Stream" doesn't need a "strategy" because it exposes functions like this instead
>                                    .map(Subtask::get) // "structured" comes into play here, you can't call terminating operators without first calling "join"
>                                    .toList();
>

This could be nice actually, but I would just create something like
this on top of STS, since an API like this could easily end up with
unwanted limitation. If you have a working implementation of something
like this, I would be curious to see it. Though I suspect an actual
implementation has to go through some iterations (at least, when I'm
designing APIs like this, I always have to seriously review my
original idea). In this idea - for example - I can't see how you would
do a conditional termination of starting new workers in a loop. For
example, if this was a server waiting for TCP connections, and then it
needed to fork new tasks for each incoming connection, I'm not sure
how that would look. And also compare how particular cases would
compare against `Stream`, because your example looks like more of a
candidate of parallel `Stream`.