[weld-dev] Legal bean type question

[Matej Novotny]

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 at gmail.com>
> To: "weld-dev" <weld-dev at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev