Back to Csharplang

C# Language Design Meeting for Apr 8, 2024

meetings/2024/LDM-2024-04-08.md

latest3.0 KB
Original Source

C# Language Design Meeting for Apr 8, 2024

Agenda

Quote of the day

"if true == 1 then why is that an error?" "cause u forgot parens"

Discussion

Implementation-specific documentation

https://github.com/dotnet/csharplang/issues/7898

The proposal is for Roslyn to consistently specify behaviors that aren't covered by the C# Standard.

There are various differences between what the C# Standard says and what the Roslyn C# compiler does. Some of these are places where the spec offers leeway - implementation-specific and implementation-defined. Others are deviations where the compiler doesn't follow the spec, e.g. because of a bug. Sometimes there are good reasons for such bugs not getting fixed; for instance there may be reasonable code depending on the current non-standard behavior, and it would be a breaking change to fix.

The Standards committee is in the process of standardizing nullable reference types, which is quite unique in that much of its impact is through warnings, which often aren't considered the purview of the specification. The rules for when exactly the warnings are issued are quite intricate. How much of that behavior should be in the Standard? For the parts that wouldn't be, to what level of detail should the Roslyn behavior be specified elsewhere?

Collection expressions are an example where the compiler needs wiggle-room around which exact types it creates and how it populates them, and reserves the right to change its choices without warning. The spec - and standard - should simply say what is guaranteed and what isn't.

The Standard has an annex that lists undefined, implementation-defined and unspecified behaviors.

Roslyn already has a document (although incomplete) listing known deviations from the Standard. We could expand that, or add sibling documents next to it, to include other Roslyn-specific behavior as suggested in the proposal.

Conclusion

For the issues in section B3 of the annex, "Implementation defined behavior", we want to document Roslyn's approach, since these are gaps deliberately left by the Standard for the implementation to fill.

In addition, with respect to section B4, "Unspecified behavior", we want to specify the behavior of item 2 on the representation of the true value, since Roslyn has made decisions here that are observable and affect interoperability with other languages.