Added: LDM Notes for October 13th, 2021

[333fred]

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

Agenda

1. Revisiting DoesNotReturn
2. Warning on lowercase type names
3. Length pattern backcompat

[HaloFour]

How about warning on any types named _ also?

[CyrusNajmabadi]

it came up in the discussion, can't remember where we landed on it. however, i don't think that helps that much as the _ tends to not hit the type name case, but rather the everything else name case. i.e. using it as the name of a parameter, etc.

that domain (non-type name) is so broad and disastrous, it's much tougher for us to institute rules on what is/isn't allowed. Indeed, there have been times we encourages use of _. THis differs from type-names where neither we, dotnet, stylecop, or the rest of the ecosystem has embraced lower-case-names.

[333fred]

I wouldn't say we landed anywhere on it. I think that's a separate conversation.

[HaloFour]

Yes, I realize that warning on use of _ as an identifier was too thorny. Seems much less so as a type name, but also probably doesn't provide much of a benefit unless you can think of any cases where the language might want to extend the use of discards as a language feature where the syntax might overlap type names and treating it as a contextual keyword isn't sufficient.

[alrz]

It's already championed at #4460. An early warning was indeed discussed in that context.

[PathogenDavid]

Instead, this warning is about trying to ensure that C# has design space to work with that doesn't break users who upgrade to new C# versions.

Has this actually been a problem to the point where it's compromised the design of a language feature? I feel like outside of record you all have been pretty good about having new keywords be contextual and not breaking old code.

(As an aside, does anyone have a link to the notes banning of types named record? All I could find was 2020-08-24 and that's just the final decision rather than the reasoning behind why it was a problem. The problematic scenarios I have been able to come up with in SharpLab so far don't feel very compelling.)

We've heard no complaints about this change

I feel like you didn't hear any complaints about this change because it was such a narrow change. I feel like trying to reserve all lower-case names as special in a 21-year-old language is quite a bit more aggressive than retroactively taking record.

We would definitely be disabling this warning. We use float3/int2/bool4/float4x4/etc for vector/matrix types because they're so fundamental to game development they might as well be builtin. (It also makes it easier to context switch between C# and shader code.) This isn't weird indie game developer having dumb opinions either, Unity separately arrived at a similar design. Anyone who uses GlmSharp/GlmNet over other .NET vector math libraries also seems to prefer this pattern.

On top of that it's going to cause friction with automated generation of interoperating with non-.NET things (whether with native code or a remote web service) where typical .NET naming conventions do not apply.

[jnm2]

We would definitely be disabling this warning. We use float3/int2/bool4/float4x4/etc for vector/matrix types because they're so fundamental to game development they might as well be builtin.

Names containing digits won't be affected by the warning.

[CyrusNajmabadi]

We would definitely be disabling this warning. We use float3/int2/bool4/float4x4/etc for vector/matrix types because they're so fundamental to game development

None of those types would fall afoul of the warning here.

On top of that it's going to cause friction with automated generation of interoperating with non-.NET things (whether with native code or a remote web service) where typical .NET naming conventions do not apply.

Over the years we've provided many tools to help generators sidestep language issues (like the global:: disambiguating mechanism). The approach that would work here would be to preface with @, or just have the generator emit a #pragma warning disable ... at the start of their generated file.

[CyrusNajmabadi]

@PathogenDavid see comments here: dotnet/roslyn#56653 (comment)

[CyrusNajmabadi]

Has this actually been a problem

Yes. This adds significant cost to the team. This happens in the design process, where at have to attend an inordinate amount of time accounting for this. It then affects both the compiler and ide which must spend many cycles safely implementing things and ensuring that there will be no problems. It also adds a lot of cost and complexity to the actual code that needs to handle these cases. Ask these things slow us down a real amount and take real resources (both design and impl) away from other work.

[CyrusNajmabadi]

(Also I do want to note that part of my issue is that it sounds like you all want to make it a warning on the authoring side and the consumption side. If it's only on the authoring side I think this is much less of a problem.)

We would likely warn on both sides.

[CyrusNajmabadi]

Also you all can beat the drum on how this isn't a code style thing, but for anyone who doesn't follow this repo it's going to be perceived as a code style thing

That doesn't concern me. It's not a code-style thing. It's about the design space of the language. I'll be happy to write something up to that effect if we end up doing this.

[CyrusNajmabadi]

or a warning disabled in every project for a situation they perceive as normal and common

This doesn't sound like an issue to me. indeed, it's why we believe we should take this route. If this project believes it is normal and common, then they can believe that. We are simply telling them our perspective that this is discouraged. Discovering that something you do is discouraged just means you've learned more than you did before. What you want to do with that learning is up to you.

[CyrusNajmabadi]

We've always been able to problem solve around the issue, but we don't want to problem solve around the issue anymore because it sucks up so much time.

Yes. 'time' is a resource. And the lack of it is arguably the single most limiting factor in our work. Needing to expend excessive effort on issues that are likely to not hit users but have some possibility of hitting users directly compromises our ability to ship features at a cadence that people have been steadfastly complaining about for decades. See some of my other posts in this discussion on how this works out. We may end up having to spend excess weeks or months on a potential speculative problem that may not exist just to ensure absolutely no breaks. However, this means weeks or months not spent on directly valuable features to the entire ecosystem. In other words, the time spent on the concern about the possibility of this problem arising is massively skewed versus time spent on actual value we know will be useful.

[sab39]

but from my perspective most additions to C# have been pleasant to use and generally don't feel like they were bogged down some big compromise with legacy cruft.

Ha - I remember going back and forth with Cyrus on the topic of how broken the design for Nullable was before it was added, and the last-minute CLR change that happened to make it less broken. Even back then it was obvious that the way Nullable was being implemented was a compromise based on what was achievable in a short time to fix the most serious problems with what they'd shipped in the earlier preview releases at the time. (Not that I don't hugely appreciate the fact they did rush those changes in!)

Think about how many of the thorny dilemmas and compromises that were needed for NRT would have gone away if only the 2.0 framework and language hadn't given Nullable Value Types so much legacy cruft!

[MgSam]

Warning on all lowercase type names sure feels like throwing the baby out with the bath water. It seems like an extreme breaking change to make with minimal benefits. There is zero doubt this will severely break customers who have lowercase types and treat warnings as errors. I can't imagine how the benefit that you might in the future use another context-sensitive keyword is worth this huge break. If new features start at -100, I can see this maybe getting to -90.

The argument that this isn't enforcing style also seems flimsy at best. Lower case type names are a thing in lots of other languages, eliminating them in C# means you are codifying a preferred style into the compiler; I don't see how that is even debatable.

I also see some legitimate use cases for lowercase type names in C#. For example, modeling the API of an external system (likely written in some other language with different style rules). If this is done via code generation, or maybe even dynamically at runtime, you could easily end up with lowercase type names.

Yes. This adds significant cost to the team. This happens in the design process, where at have to attend an inordinate amount of time accounting for this. It then affects both the compiler and ide which must spend many cycles safely implementing things and ensuring that there will be no problems. It also adds a lot of cost and complexity to the actual code that needs to handle these cases. Ask these things slow us down a real amount and take real resources (both design and impl) away from other work.

Hasn't the experience with record shown that you don't need to spend so much effort when you do need to reserve a new word?

Also, not to be rude, but your customers time is a lot more important than your time. You're not building the product for yourselves, after all. This is true for all of us that build commercial products.

[MgSam]

I doubt this. Esp. as users can both disable the warning or just add @ to silence things.

I've been reading your LDM notes since they've been public, and you guys have agonized over the years when or when not to add new warnings because of not wanting to break customers with warnings set as errors. My assumption from that has been that you've identified it as a major problem when you do so. If that's changed then I'm all for adding new warnings.

Anecdotally, it is not a problem for any org I've ever worked in.

[CyrusNajmabadi]

and you guys have agonized over the years

Yes. As I said, it occupies an inordinate amount of time and energy that reduces our ability to efficiently develop and ship beneficial features to the entire ecosystem. It is a high tax that keeps getting higher.

This is particularly painful as the impl must get continually more and more complex to not only support ask these contextual things, but it must support their combinations together.

[CyrusNajmabadi]

Anecdotally, it is not a problem for any org I've ever worked in.

Great :-)

We also think this will not be a problem for most users. And we intend to provide tools to help the users that are negatively impacted here.

[333fred]

To be clear, this will be a warning wave warning. It's not something you'll see until you update to presumably .NET 7, and it will be easy to turn off if needed.

[CyrusNajmabadi]

My assumption from that has been that you've identified it as a major problem when you do so.

The calculus has changed. What was only 'expensive' in the past to support has not only moved to 'extremely expensive', but also 'highly design restricting'. We have to spend a lot of time examining (and then possibly eliminating) good designs because of this. Or we have to go down very costly routes (to design, impl, test and maintain) to get the design we want while avoiding the extremely unlikely (but possible) collision.

This is a lot of work across many people to take something "very unlikely to happen" down to "impossible". That's not an effective use of time or resources. Ideally we could focus the bulk of our efforts on the high value cases that do exist instead of the low value stuff which may not even exist in the wild.

This proposal allows us that for one class of syntactic issues.

[xoofx]

Hello there, (following the comment from @PathogenDavid )

In Unity, we are using lower-case names for some special types that we consider as "primitives" (e.g float4)

So we have 2 questions:

• Will it be possible to disable this warning project wide?
• Does it apply only to declarations or If another project is consuming these names (e.g method with a parameter having these types), it will propagate to users projects?

[xoofx]

My apologize, I cross posted on the Roslyn issue as well, and @CyrusNajmabadi gave a response there