LDM Notes for October 9th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-10-09.md

• Triage
  • ReadOnlySpan initialization from static data
  • Embedded Language Indicators for raw string literals
  • list-patterns on enumerables
  • Make generated `Program`` for top-level statements public by default
  • CallerCharacterNumberAttribute
  • Add private and namespace accessibility modifiers for top-level types
  • Require await to apply nullable postconditions to task-returning calls
  • is expression evaluating const expression should be considered constant

[DavidArno]

This is a good set of items looked at with generally positive outcomes. All very encouraging.

But two items are a cause for concern for me:

• Make generated Program for top-level statements public by default

I'd like to see this proposal killed dead ASAP. Viewing Program.Main as part of the public API is a huge mistake in my view. I've always viewed it as a private hook for the runtime to access the true entry point to the code:

internal static class Program
{
    private static void Main(int[] args) => new SomePublicClass().EntryPoint(args);
}

All top level API tests then use SomePublicClass. Top level statements are great in that they help enforce that principle by making that runtime entry point "unspeakable". Loosening this - especially by making Program public - would be a huge mistake in my view.

• Add private and namespace accessibility modifiers for top-level types

I personally don't care for the idea of a namespace accessor, but many seem to want it, so if it happens, it happens. But the idea of a private accessor for types seriously concerns me. Consistency with existing features is an often-used argument by the team to shape new features. One thing that is current highly consistent in the language is that the default scope modifier is the most encapsulated. Introducing a private modifier to types would break that consistency as when InternalsVisibleTo (IVT) is used: internal would be the default despite being less encapsulated.

Therefore the solution needed here is to maintain that consistency by recognising that IVT isn't fit for purpose at times and to provide an alternative to IVT - strawman name: SomeInternalsVisibleTo - whereby only types eg marked public internal get exposed to named assemblies.

[jnm2]

I've always viewed it as a private hook for the runtime to access the true entry point to the code:

What would some of the differences be between making Program.Main the true entry point, and moving the true entry point somewhere else?

[333fred]

Therefore the solution needed here is to maintain that consistency by recognising that IVT isn't fit for purpose at times and to provide an alternative to IVT - strawman name: SomeInternalsVisibleTo - whereby only types eg marked public internal get exposed to named assemblies.

This is an interesting idea that deserves to be thought about in this feature. If you haven't commented it on the original issue yet, please make sure to do so.

[DavidArno]

@jnm2,

What would some of the differences be between making Program.Main the true entry point, and moving the true entry point somewhere else?

Treating Program.Main - as being solely the entry point for the runtime provides a reliable point where the real environment can be supplied to the top level testable endpoint. For example, the real filesystem is supplied as the System.IO.Abstractions implementation, environmental values can be supplied from the Environment class etc. In other words, it can be safely treated as the source of the runtime composition root, as opposed to any test version of that composition root.

If you make Program.Main a testable end point, you complicate the process of testing, as the code has to fall back on service locator style access to the runtime/test environments or you restrict the ability to easily mock the file system for example to lower levels of code.

[CyrusNajmabadi]

Nothing prevents having an interior abstraction that you can test. But if you want to test the real app, including how it handles interfacing with the real system, then this allows for that.

[jnm2]

I wouldn't see one versus the other as a 'true' entry point. They are each entry points with their own significance. Program.Main is just as valid as an API entry point as the command-line API when using the compiled .exe.

[kasperk81]

[333fred]

consts are emitted in metadata and can be seen by reflection.