J
Jon Skeet [C# MVP]
Michael Bray said:Yeah I think this is another problem of the "wording" but in this case
its the actual (correct) code that is confusing. It just seems strange
that if I receive a List<T> where T: Person that I can't add a 'Person'
to it. But of course you make perfect sense in your example - if I
receive a List<Farmer> (where Farmer: Person) then of course I can't add
a Person to it because not every person is a farmer! (E I E I O).
Exactly.
I guess when one sees "where T: Person" they can ONLY say "T is a
Person" from OUTSIDE the function. When viewed from INSIDE the
function, T is T, and even though whatever T is may be derived from
Person, you can't treat it as a Person directly.
No - in the same way that if you were passed a Farmer[] you couldn't
set an element in that to a new Person. (What I'm saying is that this
isn't a new issue with generics

Inside the function, you really do have to look at T as a macro
replacement more than simply being a Type specifier. Outside the
function, it is definitely a type specifier.
I'm not entirely sure what you mean - but I suspect everyone thinks of
generics in a very slightly different way anyway.
I guess in this case making the parameter a List<T> doesn't make
sense...
Well, it does - it's just that you can't express the constraint you
want to be able to.
it should simply return List<Person>, or for Keith's example,
it should return a List<ADUser>. But in that case the function isn't
generic, which was the whole point, so it doesn't matter anyway.
Indeed
