Well, I wasn't there when it was written in stone, but if I were to guess, it's
because of bean assignability.
You could get some unexpected results with wildcard, and the current assignability rules
surely wouldn't be able to cover that.
For instance, I am not sure you could reliably identify the types of your bean with
wildcard in it.
And then there is matching against injection point which also has a wildcard, you could
have a bean Foo<?> and an injection point that states @Inject
Foo<List<?>>
Would those two actually match? Technically, the wildcard can become List<?>, but it
also seems risky because the bean might in fact (the impl you get) be Foo<Integer>
and then it explodes.
I might be blabbering but at first look, I'd say something along those lines might be
the reason. Feel free to disagree :)
Matej
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "weld-dev" <weld-dev(a)lists.jboss.org>
Sent: Wednesday, May 27, 2020 2:57:25 PM
Subject: Re: [weld-dev] Legal bean type question
On Wed, May 27, 2020 at 1:27 AM Matej Novotny < manovotn(a)redhat.com > wrote:
Once again, please post questions like these to weld-dev mailing list.
Fair. Thanks for answering.
To answer you, I think both of the predicates would be illegal bean types.
It doesn't matter if you actually "hide" the wildcard inside another
parameter type.
OK, so "contains" truly means "contains": as the type is navigated,
any
occurrence of a wildcard encountered is illegal, no matter how "deep".
And this is because why, exactly? I'm sure there's a reason; my slow brain is
just not seeing it this morning.
Best,
Laird
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev