Re: diamond operator
Arivald wrote:
It will be better to provide "auto" type detector, like in C++.
For example, instead of:
Map<Integer, List<String>> map = new HashMap<Integer, List<String>>(=
);
use:
auto map = new HashMap<Integer, List<String>>();
...and "map" variable will be resolved at compile time to
HashMap<Integer, List<String>>.
This allow very handy construct, like:
auto data = SomeService.getProviders();
If 'auto' is a type, it should begin with an upper-case letter. If it's not=
, you should explain what you intend.
In this case type of "data" will be deducted [sic] from return type of
SomeService.getProviders().
This will save lot of typing. And save refactoring time in case if
It will save virtually no typing compared to current Java idioms.
getProviders return type changes. And will auto-adapt to changes in
libraries.
This idea is incompatible with the current direction of type inference, whi=
ch is in the other direction, and with Java's strong typing philosophy, and=
apparently the Powers That Be disagreed that your idea is better, as they =
didn't implement it.
Your suggestion:
auto map = new HashMap<Integer, List<String>>();
Current idiom:
Map<Integer, List<String>> map = new HashMap<>();
Not much difference in typing, certainly not enough to get your knickers in=
a twist over.
Your suggestion:
auto data = SomeService.getProviders();
which you describe as "very handy", but violates strong typing, which requi=
res that the compiler know the type of 'data'. If the (presumably static) m=
ethod you describe were to change its return type, it would break the clien=
t code that relies on knowledge of the type of 'data'.
The current inference direction is that the generics of a method declaratio=
n are resolved by the invocation context, when possible:
Map<Integer, List<String>> data = getProviders();
where the declaration of the method is something like:
public Map<T, U> getProviders();
Type inference tells 'getProviders()' what types 'T' and 'U' are.
Your suggestion would break those.
So it won't happen for those big reasons.
You should understand that changes to the Java language must meet at least =
two criteria, irrespective of whether they even provide value (which I don'=
t see that yours does):
- they must not break Java (which yours does), at least not too much,
- they must provide enough value to justify making any change at all (whic=
h yours doesn't).
--
Lew