• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Has anything changed with varargs?

 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just so you know, I've read all the warnings about varargs and heap pollution, but has anything changed about the way varargs are handled?

I recently created a silly little "array view" class for myself, and I've come to the conclusion that ArrayList's typed toArray() method
(<T> T[] toArray(T[] a))
could possibly be redundant.

Why? Because if, instead of the standard superclass constructors, it had offered:its toArray() method could have been specified as:
The real eye-opener to me was the fact that it works even when no arguments are supplied, ie:
  String[] strings = new ArrayListX<String>().toArray();
doesn't throw a runtime exception, and
  System.out.println( new ArrayListX<String>().toArray().getClass().getComponentType() );
returns:
  class java.lang.String

Obviously you need to be careful if the type itself is typed, but otherwise I can't seem to break it; which makes me wonder if arrays are quite as "non-reifable" as we thought.

Is this new or am I missing something? (very possible )

Winston
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've checked the documentation, but nowhere does it say that the return type must be an actual Object[]. However, some users may expect that and overwrite elements with objects that are not compatible, so their code would be broken if the type changes.

Another thing I was wondering is signature compatibility. For instance, Collections.min and Collections.max have the ugly looking <T extends Object & Comparable<? super T>>. That extends Object may seem superfluous, but it really isn't. If they had changed it to <T extends Comparable<? super T>>, this would be erased to Comparable, and the return type (and therefore the signature) would change. Code compiled against pre-generics code would break because these would be looking for a method with signature (Ljava.util.Collection;)Ljava.lang.Object; while the actual method would be (Ljava.util.Collection;)Ljava.lang.Comparable;.
However, because E is not bound, E[] toArray()'s signature would still be ()[java.lang.Object;, so that can't be an issue.


What I do miss though (in Collection) is public <T> T[] toArray(IntFunction<T[]>), which would allow us to use collection.toArray(String[]::new). Now we have to use a stream to do that:
 
Saloon Keeper
Posts: 15488
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:Is this new or am I missing something? (very possible )


I think you're missing the fact that lists don't have a fixed capacity. ArrayList needs to be able to create new arrays, therefore its array field can't be of type E[], but must be of type Object[]. The clone() method wouldn't have provided the correct runtime type.

I wouldn't say the method was redundant. Unfriendly? Yes. I agree with Rob that now, with the introduction of functional interfaces, they could have given List a toArray() method that takes an array factory, rather than an array.
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, this question puzzles me for a different reason. clone() might not be usable, but Arrays.copyOf() certainly is. It's implemented using the reflective Array.newInstance(), which in turn is implemented using the native Array.newArray().

This means that even ArrayList could have had a private E[] field, which could have been initialized and grown using the Arrays.copyOf() method.

I speculate that it was not possible to switch to an E[] field, because ArrayList already offered the parameterless constructor in the pre-generics days, which is unable to initialize a generic array.
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To think all of this is a result of arrays being covariant. If you ever decide to design your own language that includes arrays, make them invariant. If they had been invariant in Java, then it would also have been allowed to instantiate generic arrays: elements = new E[newLength];
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:I think you're missing the fact that lists don't have a fixed capacity. ArrayList needs to be able to create new arrays, therefore its array field can't be of type E[], but must be of type Object[]. The clone() method wouldn't have provided the correct runtime type.


But that's just the point: It does; otherwise the assignment I showed would throw an exception at runtime.

array.clone() replicates array's component type; and for resizing, you have Arrays.copyOf(array, newSize), which does the same.

What surprised me was that a generically typed "empty" vararg parameter generates a correctly-typed 0-length array.
Furthermore, the compiler (I assume) also distinguishes between an uncast null (ie, new ArrayListX<String>(null)) - which it assumes to be a null array - and a cast one (ie, new ArrayListX<String>((String) null)), which it takes to be an element in the array. And that applies even if the type is Object.

And the nice thing about it is that, since the internal array is now properly typed, the class requires no casts whatsoever, and type safety is guaranteed by generics. Currently, ArrayList defines an internal Object[] and explicitly casts (and presumably suppresses warnings for) every value returned from it.

I wouldn't say the method was redundant. Unfriendly? Yes. I agree with Rob that now, with the introduction of functional interfaces, they could have given List a toArray() method that takes an array factory, rather than an array.


I've not come across array factories yet, but varargs seem to do just fine for this case. What I'm wondering is if the behaviour I'm seeing is new, or if they've always worked this way. If so, I have a new respect for varargs.

Thanks for your comments.

Winston
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:I've checked the documentation, but nowhere does it say that the return type must be an actual Object[].


No, but it's declared that way. Obviously an overriding method can return an E[] because of covariance, but the presence of the overloaded version suggests that it is normally the way to return a typed array - and of course it's needed for the current implementation of ArrayList.

What I do miss though (in Collection) is public <T> T[] toArray(IntFunction<T[]>)...


Yeah, I can see I'm going to have to do some reading up on these new things. Lagging way behind at the moment...

Thanks for your interest.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:And the nice thing about it is that, since the internal array is now properly typed, the class requires no casts whatsoever, and type safety is guaranteed by generics. Currently, ArrayList defines an internal Object[] and explicitly casts (and presumably suppresses warnings for) every value returned from it.


I've came to the conclusion this is because they added the parameterless constructor before 1.5, and there's no way to use E[] internally without breaking existing code that calls this constructor. Other than that, I agree that it should be completely possible to do this in a new arraylist implementation.

A minor inconvenience is that, for methods that take an Object (like contains()), you should reeally do comparisons from the array value's standpoint - ie, elements[i].equals(o), rather than o.equals(elements[i]).


I don't understand what you mean. The two expressions should be equivalent.

I've not come across array factories yet, but varargs seem to do just fine for this case.


I'm referring to Stream.toArray() accepting an array factory (in this case, IntFunction<A[]>), which Rob mentioned could have been added to the Collection interface. They could have added a parameterless toArray() method that returns a generic array, but this would have broken every collection implementation with a parameterless constructor (which, if they follow the advice in the Collection contract, includes ALL of them).

What I'm wondering is if the behaviour I'm seeing is new, or if they've always worked this way. If so, I have a new respect for varargs.


Yes, from the start

Actually, it led to some problems when the designers retrofitted methods like Arrays.asList(), which used to take an Object[] instead of a T... :
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

A minor inconvenience is that, for methods that take an Object (like contains()), you should reeally do comparisons from the array value's standpoint - ie, elements[i].equals(o), rather than o.equals(elements[i]).


I don't understand what you mean. The two expressions should be equivalent.


Ah, they should be; but they aren't. I actually removed that sentence after you read it because the same requirement applies to the existing implementation; but since I wasn't quick enough, let me explain:

If you use o.equals(elements[i]), I could supply a spurious type that allows comparison with Strings (illegal of course) to ArrayListX<String>.contains() and get a "false positive" match.
With elements[i].equals(o) that can't happen with either version, because I already know that elements[i] is a String.

I'm referring to Stream.toArray() accepting an array factory (in this case, IntFunction<A[]>), which Rob mentioned could have been added to the Collection interface. They could have added a parameterless toArray() method that returns a generic array, but this would have broken every collection implementation with a parameterless constructor (which, if they follow the advice in the Collection contract, includes ALL of them).


Yes, I understand that; but it seems to me that that advice could be updated now, since a
SomeCollection(E... values)
constructor allows subclasses to call super(), which I'm pretty sure is why they added the advice in the first place.
Furthermore, I'd say that such a constructor would be applicable (and quite nice to have) for any existing collection.

Yes, from the start


Ain't programming amazing? You really do learn something new every day. I don't know how many times I've used varargs, but it never occurred to me to use them as an "array typer". I also wonder if it might not be possible to use the same technique to create a generic array generator, viz:Unfortunately, I'm not running v8 yet, but it seems to work fine on v7 in principle.

It should probably be added that this behaviour ONLY applies to constructors. If you try the same thing with a method, it returns an Object[].
However, the constructor behaviour works as expected even if you don't supply a type in your new call.

Actually, it led to some problems when the designers retrofitted methods like Arrays.asList()...


I don't quite follow that one, because I can't replicate the behaviour you describe, even if I assign toArray() output to an Object[]. It always prints out the contents for me.

But thanks again for your interest.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:If you use o.equals(elements[i]), I could supply a spurious subtype of CharSequence that allows comparison with Strings (illegal of course) to ArrayListX<String>.contains() and get a "false positive" match.
With elements[i].equals(o) that can't happen with either version, because I already know that elements[i] is a String.


Switching the order just hides the fact that the program is bugged. Comparing using the array elements first won't work if your collection has CharSequence as the generic type argument, and you add rogue instances.

Furthermore, I'd say that such a constructor would be applicable (and quite nice to have) for any existing collection.


Agree.

Ain't programming amazing? You really do learn something new every day. I don't know how many times I've used varargs, but it never occurred to me to use them as an "array typer". I also wonder if it might not be possible to use the same technique to create a generic array generator, viz:

...

It should probably be added that this behaviour ONLY applies to constructors. If you try the same thing with a method, it returns an Object[].


Not only constructors:
I would strongly discourage you from writing APIs like this though. While you can certainly use generic varargs this way, it makes the API hard to understand because conceptually, that's not what varargs are for. If you're reinterpreting "zero or more" to mean "zero", people are going to get lost. Only use it when the values provided are actually going to be used, which is not the case in your ArrayGen constructor. Collection constructors on the other hand, great!

I can't replicate the behaviour you describe, even if I assign toArray() output to an Object[]. It always prints out the contents for me.


I may have misremembered that one, I'll have to look it up again. It's in Effective Java: Use varargs judiciously.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Switching the order just hides the fact that the program is bugged.


Have to disagree with you there. I may not have written the spurious object that gets passed, but doing the comparison the "right" way ensures that my collection class can't be "fooled" by a cracker. So I'd say it's simply defensive coding.

And forget the CharSequence; it's irrelevant. You read so darn fast I don't have time to correct my mistakes.

I would strongly discourage you from writing APIs like this though. ... It's in Effective Java: Use varargs judiciously.


I agree with you (and Josh) in general, but in this case I'm using the vararg for a very practical purpose - correctly typing an array - which is something that has confounded us since varargs and generics were first introduced.

And for that, I'm prepared to write a bit of extra documentation.

The one thing that bothers me is that I can't find any specific documentation about this behaviour in the JLS, even when I search for 'arity'; so it's possible that it's just a feature of Oracle's javac program. If you have any suggestions where to look, I'd be eternally grateful.

On the other hand it makes sense: When you call a constructor of a typed class, you supply the type either explicitly or implicitly, so there's no reason a compiler shouldn't be able to work out the specific type of array it should generate for a varargs parameter. With a method it's a little harder, since by the time the compiler gets around to parsing it, it may only know the erasure type of the class.
static (and possibly typed) methods?: Dunno, but I trust your findings. And again, the compiler probably has more to go on (like a target type) to work out what type of array is needed.

I can't believe, after 14 years of Java (and 39 on the job) that I'm having so much fun with something so (seemingly) basic.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:The one thing that bothers me is that I can't find any specific documentation about this behaviour in the JLS, even when I search for 'arity'; so it's possible that it's just a feature of Oracle's javac program. If you have any suggestions where to look, I'd be eternally grateful.

On the other hand it makes sense: When you call a constructor of a typed class, you supply the type either explicitly or implicitly, so there's no reason a compiler shouldn't be able to work out the specific type of array it should generate for a varargs parameter. With a method it's a little harder, since by the time the compiler gets around to parsing it, it may only know the erasure type of the class.
static (and possibly typed) methods?: Dunno, but I trust your findings. And again, the compiler probably has more to go on (like a target type) to work out what type of array is needed.



Generics are handled the same for all methods, static or not, and constructors. Type erasure doesn't come into play. When the compiler runs into generic varargs, it just creates a generic array, as if it had called new T[]{...} before passing it to the method.

The weird thing is that this completely ignores the entire reason we as programmers are not allowed to manually create generic arrays ourselves. The following code compiles!

This makes me wonder why they didn't make the instantiation of a generic array emit a warning, instead of just forbidding it.
 
Stephan van Hulst
Saloon Keeper
Posts: 15488
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's what the JLS has to say about varargs (emphasis mine): [quote=The Java® Language Specification Java SE 8 Edition]
  • If the member is a variable arity method with arity n, then for all i (1 i n-1), the i'th argument of the method invocation is potentially compatible with the type of the i'th parameter of the method; and, where the nth parameter of the method has type T[], one of the following is true:

    • The arity of the method invocation is equal to n-1.

    • The arity of the method invocation is equal to n, and the nth argument of the method invocation is potentially compatible with either T or T[].

    • The arity of the method invocation is m, where m > n, and for all i (n i m), the i'th argument of the method invocation is potentially compatible with T.

  • [/quote]
    [url=https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.1]§15.12.2.1[/url]

    The part in bold says that if the member is a variable arity method and the number of arguments is one less than the number of formal method parameters, the method is potentially applicable.

    So when is a member a variable arity method? [quote=The Java® Language Specification Java SE 8 Edition]The last formal parameter of a method or constructor is special: it may be a variable arity parameter, indicated by an ellipsis following the type.

    [...]

    If the last formal parameter is a variable arity parameter, the method is a variable arity method. Otherwise, it is a fixed arity method.[/quote]
    [url=https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.1]§8.4.1[/url]
     
    Rob Spoor
    Sheriff
    Posts: 22781
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    ArrayList could never lose its parameter-less constructor while still being backward compatible. Although new Java code wouldn't have a problem (new ArrayList<>() would simply receive zero vararg elements), existing code will definitely break. That's because that code uses the <init>()V constructor which is different from the <init>([Ljava.lang.Object;)V constructor that the varargs constructor would actually be (ArrayList(Object[])). As a result, existing code would get a NoSuchMethodError instead of calling the varargs constructor.

    That's the same reason why Collections.min and max have the extends Object & Comparable<? super T> I mentioned earlier.

    (It helps having programmed JNI a bit )
     
    Winston Gutkowski
    Bartender
    Posts: 10780
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:Generics are handled the same for all methods, static or not, and constructors. Type erasure doesn't come into play.


    Hmmm. Well my first effort at implementing ArrayGen looked like this:and it gave me two Type Safety warnings:
    Potential heap pollution via varargs parameter values - at line 4
    A generic array of T is created for a varargs parameter - at line 9
    If I add '@SuppressWarnings("unchecked")' before line 4, the one at line 9 remains, but if I add '@SafeVarargs' both disappear.

    However, in either case I get a ClassCastException if I attempt to assign to a typed array, because gen() actually returns an Object[].

    When the compiler runs into generic varargs, it just creates a generic array, as if it had called new T[]{...} before passing it to the method.


    And this is what I'm having trouble finding in the JLS - what happens when you invoke a varargs method. I actually found the para that you linked, but I couldn't make head or tail of all those i's and n's and n-1's. It also doesn't explain how it creates the array - or if it does, I can't follow it.

    The weird thing is that this completely ignores the entire reason we as programmers are not allowed to manually create generic arrays ourselves.
    ...
    This makes me wonder why they didn't make the instantiation of a generic array emit a warning, instead of just forbidding it.


    It would certainly have made things simpler.

    Thanks again.

    Winston
     
    Winston Gutkowski
    Bartender
    Posts: 10780
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Rob Spoor wrote:ArrayList could never lose its parameter-less constructor while still being backward compatible. Although new Java code wouldn't have a problem (new ArrayList<>() would simply receive zero vararg elements), existing code will definitely break.


    Yes, of course. I keep forgetting about legacy code.

    (It helps having programmed JNI a bit )


    I'll bet.

    Thanks for your help.

    I'd also be interested to know what you both think of my ArrayGen class. It seems to me like you could use it for pretty much any non-primitive Stream.
    Or maybe somebody already thought of it.

    Winston
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15488
    363
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    [quote=Winston Gutkowski] Hmmm. Well my first effort at implementing [tt]ArrayGen[/tt] looked like this:

    [...]

    However, in either case I get a ClassCastException if I attempt to assign to a typed array, because [tt]gen()[/tt] actually returns an [tt]Object[][/tt].[/quote]
    I was wrong to say type erasure doesn't come into play. However, it still works the same for both constructors and methods. The reason you're getting an [tt]Object[][/tt] is because [tt]apply()[/tt] doesn't provide [tt]gen()[/tt] with a reifiable type.

    [quote]And this is what I'm having trouble finding in the JLS - [i]what happens when you invoke a varargs method[/i]. I actually found the para that you linked, but I couldn't make head or tail of all those i's and n's and n-1's. It also doesn't explain [u]how[/u] it creates the array - or if it does, I can't follow it.[/quote]
    [quote=The Java® Language Specification Java SE 8 Edition]

    If m is being invoked with k n actual argument expressions, or, if m is being invoked with k = n actual argument expressions and the type of the k'th argument expression is not assignment compatible with T[], then the argument list (e1, ..., en-1, en, ..., ek) is evaluated as if it were written as (e1, ..., en-1, new |T[]| { en, ..., ek }), where |T[]| denotes the erasure (§4.6) of T[].

    [/quote]
    [url=https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.4.2]§15.12.4.2[/url]

    So really, this means that the compiler just translates [tt]<X>call(a,b,c);[/tt] to[tt] call(new X[] {a,b,c});[/tt] [b]IF[/b] [tt]X[/tt] is a reifiable type.

    [quote=Winston Gutkowski]I'd also be interested to know what you both think of my ArrayGen class. It seems to me like you could use it for pretty much any non-primitive Stream.
    Or maybe somebody already thought of it. :wink:[/quote]
    The designers did: [code=java]Arrays.asList("A", "B").stream().toArray(String[]::new);[/code]
     
    Winston Gutkowski
    Bartender
    Posts: 10780
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:So really, this means that the compiler just translates <X>call(a,b,c); to call(new X[] {a,b,c}); IF X is a reifiable type...


    Aha!! So that's where it is. Thanks a lot, and have a cow.

    The designers did:..


    OK, but that doesn't seem particularly generic to me. Wouldn't it be nice to simply write '.toArray()' for any Stream and have it return a correctly typed array?

    But thanks VERY much for finding me that para.

    Winston
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15488
    363
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    They probably thought that using T... was not appropriate, and I agree with them

    Thanks for the cow Winston. Have one back, this was very stimulating!

    P.S. while trudging through the JLS, I found something new that they apparently added in Java 8. You can now write something like this:

    This is called a "receiver parameter". You can't actually do anything with it, but in Java 8 they added Type Annotations, and they added receiver parameters to give the programmer the opportunity to annotate 'this'. The example they give:

    In practice not very useful for you or me, I imagine, but it made me scratch my head.
     
    Marshal
    Posts: 79153
    377
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Which section in the JLS? Do you know any more about the read only annotation? That sounds very interesting.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 15488
    363
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    @ReadOnly was only an example they gave: http://www.oracle.com/technetwork/articles/java/ma14-architect-annotations-2177655.html
     
    Winston Gutkowski
    Bartender
    Posts: 10780
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:They probably thought that using T... was not appropriate, and I agree with them


    So do I. What I don't agree with (as you pointed out) was preventing us from writing
      new T[size]
    or
      new T[] { ... }
    in context.
    It seems like a "nanny state" decision to me, and they had to know it would set geeks like me on a search for an alternative.

    Do you have a link for that "receiver parameter" stuff? It sounds really interesting (as does lots of the stuff in v8).

    Cheers.

    Winston

    [Edit] Too slow. Thanks Stephen.
    reply
      Bookmark Topic Watch Topic
    • New Topic