Added: LDM Notes for October 25th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-25.md

Agenda

1. Required members
2. Delegate type argument improvements

[HaloFour]

"Delegate type argument improvements" feels like an awful lot of work to avoid declaring custom delegates to cover those cases where Action<...>/Func<...> aren't suitable. Is there a plan to eventually extend these generic improvements across types and methods? If not it would just feel really weird that I could define Func<string, ref int, bool> but not M<T1, T2, TR>(Func<T1, T2, TR> fn) that could accept such a generic delegate.

[TahirAhmadov]

it's unclear whether the first argument is a connection string and second one is the query, or the other way around.

As with basic data types, tuples, etc. etc., there's a spectrum here. We've never advocated using things in a confusing fashion. Rather, we give the tools and let teams decide what styles and choices are best for them.

I agree that bad developers will always find a way to shoot themselves in their feet. From the perspective of language design, it's one thing to provide "good" options, and another to provide "bad" options. Whereas with Func<T1, T2> it's difficult to make a mistake like what I described, with Func<T1, T2, T3, T4> it is much easier to do so. I just hope LDM doesn't prioritize changing the language in the direction of making it easier to use things like Func<T1, T2, T3, T4> - which are objectively bad for all the reasons I've listed so far.

[TahirAhmadov]

In general, @TahirAhmadov the design and use of delegates at their inception matches what you describe "You should define your own delegates that match your given domain" and I think this still makes sense in a lot of domains. However, for libraries that are not domain specific this quickly fell out of practice when generics where introduced. In the framework these are the only delegates beyond action/func that are ever defined

public delegate int Comparison<in T>(T x, T y);
public delegate TOutput Converter<in TInput, out TOutput>(TInput input);    
public delegate bool Predicate<in T>(T obj); 

And these delegates are defined for a good reason: predicates make it clearer the delegate you are passing is used for filtering/checking. Comparison and Converter are also special use and helpful to clarify how a given delegate will be used.

So, I would say the more general a library is the less you should need to define custom delegates. For this reason I think this change is going to be super helpful for library authors but probably less useful apps.

I agree, and again, I'm not against generic delegates in principle; the ones you listed, and the simple versions of Action and Func<T> are usually fine, because the intent is obvious - if the intent is "perform an action", then Action fits perfectly. I was concerned that what I read was people saying, named delegates are all but obsolete, all delegates will be Action and Func from now on, and we'll massage whatever parts of the language that are needed to make that workable.

In my work, I do end up making libraries, not as much for public consumption but to be re-used by me and multiple teams of my larger clients. And even in libraries, I used to default to Func<T1, T2, T3, T4> type delegates - because I thought, hey it's simpler - until I realized that the readability and maintainability suffer as a result.

[TahirAhmadov]

it's unclear whether the first argument is a connection string and second one is the query, or the other way around.

And thus was born Apps Hungarian Notation, to denote a logical type apart from the actual data type that can be visually identified as different.

Also, with C# 10.0 record struct gets us pretty close to zero-cost type-safe wrappers with very little fuss.

public record struct StudentId(string id);

That's a good feature, and I would say - call me a strong typing nazi - I would use the above and named delegates. Basically, I already do delegate void ExecuteDbDelegate(string connStr, string query);, and in some cases, I'll probably change it to something like delegate void ExecuteDbDelegate(ConnStr connStr, Query query);. (Disclaimer: I don't actually have a delegate like this - just came up with this as an example.)

[HaloFour]

You're free to always make that decision, but the language team isn't going to put arbitrary restrictions on the feature based on the arity of the parameters. This is true already with tuples and with naturally-typed lambdas both of which are capable of exceeding the arity of the .NET types to which they map by default. The language team disagrees that this is a "bad" thing as does seemingly a good percentage of the audience who find the need to define custom delegates a nuisance.

[jmarolf]

In my work, I do end up making libraries, not as much for public consumption but to be re-used by me and multiple teams of my larger clients. And even in libraries, I used to default to Func<T1, T2, T3, T4> type delegates - because I thought, hey it's simpler - until I realized that the readability and maintainability suffer as a result.

I do think Func<...> has some ergonomics issues where you need to remember that the last parameter is the return type. As @RikkiGibson says I think we need to make some tooling improvements there in general. But I do not think this proposal makes Func<...> worse in any way. and generic delegates are what most libraries are using because, as you say, they don't care that the function is doing they just care that the signature matches.

As soon as you can provide a description of that the implementation of a delegate type is going to be doing then I am fine with you defining your own delegate type. But in practice most people do not re-define generic delegates with custom names or have methods that have multiple arguments that are delegate types.