Added: LDM Notes for December 1st, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-12-01.md

Agenda

1. Roles and extensions

[alrz]

Something strange about this taking precedence over discriminated unions.

[DavidArno]

@theunrepentantgeek,

For example: In Go, variable declarations that are inline to an if are scoped to the statement, which requires moving the declaration to an earlier line if you're writing anything more than a trivial guard statement. In C#, var out declarations inline to an if condition are in the outer scope, which makes the feature much more useful.

You may not like the way Go does it, but in my view they do it the correct way. I do not see this as in any way being an example of "he team took the time to get things right". The "leaky scope" feature of out var sits at odds with other similar existing behaviours in the language (not being able to access a variable defined in a try block in a catch or finally for example). It therefore it somewhat has the feel of being "half baked" about it. Further, having pattern variables leak in the same way feels very much a rushed, half-thought out decision as it causes problems with using patterns at least as much as it allows "clever" guard clauses to be written. There was certainly no "slow, steady, let's take our time over this one" feeling to that change.

I generally agree that the team taking their time is a good thing, but your example here, in my view, is not an example of that in action.

[HaloFour]

I don't think that's a fair assessment. Neither of those decisions were rushed. In fact, for much of the design of both features the team worked under the assumption of much stricter scoping. It wasn't until the team experimented with using the feature in that manner that the friction of the narrow scoping caused them to consider other options. It was decided that widening the scoping was preferable to having to add additional features for those use cases. You and I might disagree with the decision that the team ultimately made, but to classify it as "rushed" doesn't feel at all appropriate.

I can't think of too many cases where I could consider design decisions as being rushed. At worst there are cases where the communication from the team was published well after the design meetings that led to a decision and after feedback from this community could be solicited, but the team has gotten much better at that.

[TahirAhmadov]

For example: In Go, variable declarations that are inline to an if are scoped to the statement, which requires moving the declaration to an earlier line if you're writing anything more than a trivial guard statement. In C#, var out declarations inline to an if condition are in the outer scope, which makes the feature much more useful.

You may not like the way Go does it, but in my view they do it the correct way. I do not see this as in any way being an example of "he team took the time to get things right". The "leaky scope" feature of out var sits at odds with other similar existing behaviours in the language (not being able to access a variable defined in a try block in a catch or finally for example). It therefore it somewhat has the feel of being "half baked" about it. Further, having pattern variables leak in the same way feels very much a rushed, half-thought out decision as it causes problems with using patterns at least as much as it allows "clever" guard clauses to be written. There was certainly no "slow, steady, let's take our time over this one" feeling to that change.

In addition to what @HaloFour wrote about this decision not being a rushed one in any way, the actual merits of it are strong even in hindsight. The example you bring to contrast - such as try-catch blocks - are not the same as if condition. In both cases, locals declared inside the {} block are inner scoped; same applies for all blocks, including if. The if condition is different in that it's outside of the {} "then" or "else" blocks. There is no conflict there.

Re. "clever" guard closes, I'm not sure how you can improve what C# currently has.

[CyrusNajmabadi]

It therefore it somewhat has the feel of being "half baked" about it. Further, having pattern variables leak in the same way feels very much a rushed,

The decisions were not rushed. We tried both out. And we far preferred the form we shipped. This was with thorough discussion and understanding of the pros/cons of both approaches by the entire ldm.

Furthermore, you have multiple posts on csharplang that seem to be at odds with each other. Here you lament what your see as not enough time being spent to get the design you wanted. But elsewhere you push for us jumping to conclusions and not doing due diligence to understand and work through the implications of a particular decision.

[CyrusNajmabadi]

There was certainly no "slow, steady, let's take our time over this one" feeling to that change.

There absolutely was. With the experiments and designs spanning months, including experimentation.

And this was exactly a case of having to look deeply at the language and the future we want for it (including me feature work).

We made a conscious, informed, decision that the ldm agreed on, based on what constructs we thought we wanted (or did not want) and how this work would fit into that.

I find your position particularly odd as I remember you being very vocal about this at the time, even as we spent a lot of effort explaining our reasoning and the results of our trials with this. I completely understand you not likely the outcome. But you are backfilling a story here to make your disappointment feel more justified. I'm other words: oh, if they'd just taken more time and had been more diligent they would have realized I was right.

But that's not the case here. In the intervening years there team has felt more strongly that the final position we landed on was her right one (which is not always the case). Indeed, an ldm member who felt the other way was better has himself expressed that this was a good decision to change course here and it was very fortunate that we didn't just settle on the original design, but did the diligence to try things out, incorporate feedback and revise while we still could.