Added notes for July 19th and 26th, 2021

meetings/2021/LDM-2021-07-19.md

@@ -0,0 +1,39 @@
+# C# Language Design Meeting for July 19th, 2021
+
+## Agenda
+
+1. [Global using scoping revisited](#global-using-scoping-revisited)
+
+## Quote of the Day
+
+- "Any guesses on how many tries it took for me to spell that correctly?" "Well, you misspelled it."
+
+## Discussion
+
+### Global using scoping revisited
+
+https://github.com/dotnet/csharplang/issues/3428
+
+The SDK team is currently considering how and where they will generate default global usings for .NET 6, and we want to take another look at our decisions around the
+[scope of global usings](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-03-15.md#global-usings). Previously, we decided that global usings should
+be thought of as being copied and pasted into every file, and that there is no separate outer scope for global usings. However, there are some type names that are relatively
+common in .NET, such as `Task`, that would likely be part of a default set of SDK global usings (as `using System.Threading.Tasks.Task;` is another way of saying "Use C# 5
+features please"). If there is no separate global using scope for these types, however, we'd introduce ambiguities for these types.
+
+There are a number of complexities to the separate scope idea that would be equally as painful for users, in potentially subtler ways. In particular, extension method lookup
+across multiple sets of usings can be tricky, and explaining the intricacies of the lookup rules is complicated, even for language designers talking to other language designers.
+This would hit Linq hard in particular, as `System.Linq` is on the shortlist of default global usings, but users often add their own versions of the extension methods to
+customize particular behaviors or performance characteristics for particular scenarios. In these scenarios, users would have to add a manual `using System.Linq;` at the top
+of their files, which is the same problem as we'd be trying to address by having separate scopes in the first place.
+
+We considered a few compromise positions as well, such as considering global usings to be in the same scope for extension method lookup, but different scopes for type lookup.
+These are complex, both in terms of implementation and in terms of explaining to users, so we don't think this is a good approach. Instead, we think that we have a good tooling
+story around name clashes already, and we can strengthen the tooling to be aware of global using clashes and introduce global aliases to solve the issue, which is a fairly simple
+fix for the problem.
+
+Finally, we noted that even if we introduced a separate scope for global usings, this wouldn't even fix the issue permanently. The next request would be a way to separate the
+implicit usings from the SDK, and the user-created global usings.
+
+#### Conclusion
+
+Existing behavior is upheld.

meetings/2021/LDM-2021-07-26.md

@@ -0,0 +1,81 @@
+# C# Language Design Meeting for July 26th, 2021
+
+## Agenda
+
+1. [Lambda conversion to System.Delegate](#lambda-conversion-to-system-delegate)
+2. [Direct invocation of lambdas](#direct-invocation-of-lambdas)
+3. [Speakable names for top-level statements](#speakable-names-for-top-level-statements)
+
+## Quote of the Day
+
+- "You just don't want me to have poor man expression blocks"
+
+## Discussion
+
+### Lambda conversion to System.Delegate
+
+https://github.com/dotnet/csharplang/blob/main/proposals/lambda-improvements.md
+
+We've received a few bug reports from customers on upgrading to a new version of the preview SDK that existing code, targeting .NET 5, was not failing to compile
+because code that previously chose an extension method with a strongly-typed delegate type was now binding to an instance method that took a `Delegate` instead.
+While this is a break we intended to make, we wanted to revisit it and make sure that we still believed it was appropriate for these cases. While we are still
+waiting to hear back from these customers as to what their extension method was actually doing, a survery of code on GitHub shows that the vast majority of these
+are what we expected: the extension forwards from a strongly-typed delegate to the `Delegate` instance method. Given this, we believe that our original decisions
+around this feature are still what we were expecting, and that we will keep the behavior for C# 10.
+
+However, we area also concerned with not making tooling updates that break our users (beyond bugfixes, such as the ternary type inference issues in C# 9's initial
+release). This is code that has been compiling successfully for a decade or more, and we don't want to break it when the user has only updated their version of VS,
+and not actually updated to a new version of .NET (ie, using VS 2022, but still targeting .NET 5 or lower). In order to preserve this, we will bring back our
+workaround for the 16.10 release, where we changed the binding of this case depending on the current language version. It does mean that there will be a subpar
+tooling experience for upgrades involving this type of code, but we think missing codefixes are better than code that completely stops compiling.
+
+#### Conclusion
+
+We will keep the current behavior for C# 10. C# 9 and lower will have a different binding behavior, compiling as they used to.
+
+### Direct invocation of lambdas
+
+https://github.com/dotnet/csharplang/issues/4748
+
+Currently, the lambda improvements proposal states that lambdas should be directly invocable. While we think this could fall out for some scenarios, it will not do
+so for all scenarios. For example:
+
+```cs
+(() => {})(); // Infer Action, can be invoked
+(x => x)(1); // Cannot infer a delegate type on its own: would need to take the argument expression into account
+```
+
+We don't have a strong scenario for this feature at the moment: our best justification for the feature would be as a poor replacement for expression blocks, and we've
+received vocal and vociferous feedback from the community on the "poor" part of that phrase. We do think it will be odd that lambdas will be able to be assigned to
+`var` and then be invoked/used as instance receivers, but cannot be invoked/used as instance receivers directly, but we believe that if we explicitly block this scenario
+now, we will adequately preserve our design space to remove this restriction later, if we have a better scenario we want to enable.
+
+#### Conclusion
+
+Lambda and method group natural types will only be allowed to surface in specific contexts: `var`, method type inference, determining the best type of a group of types,
+and conversion to `System.Delegate`/`System.Linq.Expressions.Expression`. No direct invocation of lambdas or instance member access on lambda expressions or method groups
+will be allowed.
+
+### Speakable names for top-level statements
+
+[Two weeks ago](LDM-2021-07-12.md#speakable-names-for-top-level-statements), we made a decision that top-level statements would be sugar for a partial `Program` type in
+a `Main` method. However, a [comment on the subsequent discussion](https://github.com/dotnet/csharplang/discussions/4928#discussioncomment-1013469) gave us a separate
+idea that we had not considered in the meeting, and we wanted to bring up the idea: naming the type that contains the top-level statements after the name of the file
+the statements are in. There are a few wrinkles to this: what if the file name contains characters that are not legal as C# identifiers? Or what if there is no file name,
+and the text was passed directly to the compiler not in a file (as is possible using the Roslyn APIs)? We're also concerned by the fragility of this solution: renaming a
+file could potentially leave dangling partial types and no longer have methods in scope for the top-level statements. Additionally, C# today does not depend on file
+layout or structure for programs: file names do not have to line up with type names, and namespaces are entirely unconnected from the physical layout of files. This
+proposal would change that, and we're not sure for the better.
+
+However, the idea that we might have a future where we want to combine multiple files, each with top-level statements, into a single program is a distinct possibility.
+As we move towards the idea of `dotnet run Program.cs`, it's conceivable that a single program might have a few files for different UI stacks (for example, `WebUI.cs`,
+`ConsoleUI.cs`, and `Desktop.cs`), each of which shares a bunch of common files in the same directory. Users would then choose which to run by just saying
+`dotnet run Console.cs`, and all 3 of these UI entrypoint files would be combined into a single program, with the entrypoint selected by the file that was run. Given
+that our specific ask for the speakability feature is being able to get access to the current Assembly (via `typeof(Program).Assembly`), we think that we can protect
+future design space here by only making `Program` speakable, rather than both `Program` and `Main`. This will allow our future selves a space to design this mutli-file
+experience without worrying about having multiple methods named `Main` in the same type, as we will be able to combine these different partial `Program` types into a
+single one and name the entrypoints whatever we need to.
+
+#### Conclusion
+
+We will keep the type name `Program` and make it speakable, but we will not make the `Main` method speakable.

meetings/2021/README.md

@@ -33,19 +33,24 @@
 
 ## Aug 23, 2021
 
-## Jul 26, 2021
-
-- Lambda conversion to System.Delegate (Chuck)
-- Using filename to inform speakable type for top-level statements (Julien)
-
-## Jul 19, 2021
-
-- Scope of global usings revisited (Daniel): https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-03-15.md#global-usings
-
 # C# Language Design Notes for 2021
 
 Overview of meetings and agendas for 2021
 
+## Jul 26, 2021
+
+[C# Language Design Notes for July 26th, 2021](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-07-26.md)
+
+1. Lambda conversion to System.Delegate
+2. Direct invocation of lambdas
+3. Speakable names for top-level statements
+
+## Jul 19, 2021
+
+[C# Language Design Notes for July 19th, 2021](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-07-19.md)
+
+1. Global using scoping revisited
+
 ## Jul 12, 2021
 
 [C# Language Design Notes for July 12th, 2021](https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-07-12.md)