Generic parameter of StructuredTaskScope

[Attila Kelemen]

To be honest, I somehow missed that ShutdownOnSuccess does have a type
argument (probably my brain generalized from ShutdownOnFailure, which
is probably the more commonly used).

But otherwise yes, it is a bit strange that ShutdownOnFailure denies
me the option when it only saves me two characters "<>", and if saving
character is the goal, then they could have factory methods (and these
two classes don't even have to be directly exposed, since they are
final anyway).

Alan Bateman <Alan.Bateman at oracle.com> ezt írta (időpont: 2023. máj.
13., Szo, 8:38):
>
> On 12/05/2023 21:11, Attila Kelemen wrote:
> > Hi,
> >
> > There is an inconsistency in the treatment of the generic parameter of
> > STS. Namely, that while it was deemed important to know the common
> > base type of the result of the forked tasks; Surprisingly, its two
> > common implementations do not provide this feature. How come that in
> > the STS implementations believed to be used almost always are not
> > believed to find this feature useful? I mean, in the use cases I can
> > think of relying on this generic parameter, I would happily rely on it
> > even in the default implementation.
> The API has to support usages where the tasks are homogenous or
> heterogenous, the JEP has examples of both. The type parameter is useful
> for the former, less so for the later where you have to pick a LUB or
> Object. ShutdownOnSuccess uses the type parameter as it's for racing
> subtasks that produce a result of same type. ShutdownOnFailure doesn't
> expose an API for the result so it doesn't use the type, is that your point?
>
> -Alan