> On 9 Nov 2015, at 19:55, Roger Riggs <roger.ri...@oracle.com> wrote:
>
> Hi Paul, Alan,
>
> What are the chances that varargs will be updated at some point in the future
> to use
> Lists instead of arrays? It would be a bit of thrash to try to avoid varargs
> if varargs
> is likely to be updated. It is a bit awkward at the moment though.
>
> I'd hope that at some point varargs caller syntax could handle automatically
> the case where the method
> invoked accepts either a List<T> or T[]. Currently, providing a T[] is able
> to use the array as is.
> It would make sense that it could also convert a List<T> to T[] as part of
> code generation.
>
> For the existing Arrays.asList( pb1, pb2) or JEP 269 List.of(pb1, pb2)
> force the developer to
> type extra stuff and create more objects than the current varargs usage.
>
Not necessarily, it depends on the literal size. Recall that varargs packs the
elements into T[]. For a small number of elements a factory method can pack the
elements into a List impl without an internal array. And for this case it’s all
in the a wash giving the forking of processes.
> Where is varargs going?
>
Nowhere :-) I doubt varargs is going to be replaced, and the convenience
collection factories will use it too. There would likely be circular
dependencies and backwards compatibility issues and we would need to work out
some sort of bridge mechanism. What we need for better varargs support is
frozen arrays, and superior auto-unboxing/eliding optimizations if things
inline.
I like varargs! it’s very convenient, it’s great for small literal expressions,
but one can quickly rub up against it. List is more easily composable than
varargs.
I have run up against it many times with:
public static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs) {
public static CompletableFuture<Object> anyOf(CompletableFuture<?>... cfs) {
Accepting a Collection<?> would have overall been more convenient to me. In
fact i should propose such additions to CF :-)
Having both varargs and List would be acceptable (as is the case for
MethodType). But if there is to be only one i would choose List.
> And, will List<T> toArray() ever be able to properly create T[]?
>
That may be possible, there is an issue tracking this, it keeps getting bumped
down in the the priority list of things to do.
Paul.
