Ladies and gentlemen, the Func class in C#
Posted Apr 30, 2023, 1:42 PM UTC
019
It's not a horror to save time by auto generating accurate documentation instead of overthinking it to appease someone who posts low effort crap like this to reddit to farm karma.
18
I agree. It’s not pretty, maybe ugly, but certainly not horror.
5
Found the person that wrote it
-14
I once used source generators to emulzte variadic generic types, so it can be better, but again lambdas are problematic (allocation wise) and abusing them is bad, having annoying restrictions somehow helps reducing their use a bit
6
Imagine needing 16 parameters, what a mess.
5
In fact why use any parameters at all? Superglobal variables ftw 💪
5
Well at least the name is not IFunc
4
Because it's a delegate, so it's a different stuff.
2
[deleted]
1
The documentation has to be like this, it should be descriptive. And yes you shouldn't need 16 arguments, but you can and because of this delegates should support this. Think of it the same way you think of the dumb user, for programming languages we are the users, and some of us will do some dumb stuff.
Users can define their own delegates with as many parameters as they desire. Having Func defined with up to 16 parameters feels like an endorsement
That's true, someone should open a GitHub issue so they can add more.
Delegates aren't interchangeable, having this func delegate allows communication between unrelated code.
Are you saying that if two delegates are identical in shape, an argument of the type of the first delegate can't be used where the second type of delegate is expected? In other words, delegates are nominally typed rather than structurally typed? I guess that fits C# but it does seem kinda stupid. I would expect them to behave more like interfaces than classes.
Interfaces aren't interchangeable too. Having two interfaces equal in all but name, doesn't mean you can substitute one for the other. Delegates, and interfaces are types, coming with all type constrains.
Yes, this is correct.
I think that this is usually correct and desirable, but it is slightly irksome if you are working with named delegate types and want to pass them to some other system expecting a Func (Microsoft's inconstant usage of
Predicate<T>andFunc<T, bool>being a prime example).It's funny, this sentiment has quite a bit of support from a community that also largely subscribes to the DRY dogma.
What do you mean by "community that also largely subscribes to the DRY dogma.", good programmers?
I suppose that comes off as me being against DRY as a concept. Should have perhaps used the term "guideline" or "principle".