Added: LDM Notes for January 13th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-01-13.md

Agenda

• Global usings
• File-scoped namespaces

[jnm2]

A syntax form would allow participation from source generators. We're somewhat split on whether that's a good thing or not.

In practice, source generators are shipped in NuGet packages that allow participation by including a .props file that sets the project file property. The only thing you couldn't do this way is condition the global usings based on the compilation object model.

[333fred]

This is a good point, and one that was not brought up during the meeting, though we did not get too in-depth in these arguments.

[alrz]

A syntax form might be a barrier to potential abilities to do things like dotnet run csfile

If this implies "compared to cli option", does it mean we need to always use -using flag for that particular file? This doesn't seem to be helpful when you talk about dotnet run csfile which would be usually written manually. Those files shouldn't really depend on an "external configuration" or anything like that.

A syntax form would allow participation from source generators. We're somewhat split on whether that's a good thing or not.

For namespace imports, it's probably not a good thing, but it'd be really helpful to be able to define global type aliases in generators.

If these are specified via command line flags, then there is one place to go looking for them: the project file. A syntax form would be potentially able to be spread out among multiple files.

As for the discovery, the "Imports" name is already familiar from Razor. Also you'd usually use AssemblyInfo.cs for assembly attributes and it's never been an issue that they could appear virtually anywhere in the project. Imports.cs could just go right next to it.

interaction with top-level statements

If the interesting scenario involves only one file, there is no point to use namespace directives because that means you need to import immediately. Why would anyone do this?

namepsace N;
using N;
var c = new C();
class C {}

[YairHalberstadt]

On the one hand, we're concerned about the readability of combining these things, and that the namespace statement would be too easily missed.

Given that top level statements tend to be used in executables (not libraries) with a handful of files, the namespace doesn't really matter all that much and so I don't think it matters if it's easily missed.

Also I don't see any readability issues with it myself?

[bbarry]

I'd be OK with top level statements disallowing a file scoped namespace and a file scoped namespace disallowing top level statements if it were really an issue. Is that something that is being considered?

Perhaps that restriction could be in the first version and then if there is support for removing it more work could be done.

[MgSam]

I think a syntax form of a global using makes sense, and should be easy enough to understand what's going on with proper tooling.

I am still puzzled by this "beginner scenario" you guys seem to be focused on the past few years. C#/.NET is 20 years old and consistently ranks as one of the most used platforms in the world, clearly there is not a real problem introducing it to beginners. If the goal is to compete equally with Python or JavaScript here I don't think that's ever going to happen, as static typing will always add complexity that seems obtuse to those who are just learning.

I think the best thing for beginners (and the reason .NET became successful in the first place) is the tooling stack. The fact that VB6 and then .NET Windows Forms and ASP .NET Forms shipped with WYSISYG editors made them unbeatable as tools for starting developers. Microsoft has largely forfeited that advantage as the industry has largely moved to client-side web technology stacks (though Xamarin for mobile does fill a small niche there).

I strongly disagree in the LDT's statement that the vast majority of .NET code is in simple projects. If you guys are just looking at public Github repos this introduces a huge sampling bias, as the vast majority of companies keep their code private. The people keeping C# alive are professional developers who write complex applications everyday (and actually pay Microsoft's bills via Azure, Office, and Windows licenses).

[ufcpp]

The C# official tutorial seems to use global usings substantially:

I think online playground is the best thing for beginner scenario and the C# tutorial is awesome in this sense.

However, current implementation of the tutorial is dreadful - just adding the following code before an edited code.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Program
{
    class Program
    {
        static void Main()
        {

Thus we can write a weird code like this:

We need top-level statements and global usings to avoid this kind of weird code.

[alrz]

However, current implementation of the tutorial is dreadful - just adding the following code before an edited code.

With top-level statements, they could just insert only imports to that effect.

But for the beginner scenario, I strongly believe that they actually need to see those imports in the source. I remember myself seeing stuff like print 'foo' in a code snippet and wondering where that function comes from. Hiding things does not help with this scenario.

[alrz]

interaction with top-level statements

I just had this issue with top-level statements:

Due to the generated class being in the global namespace rather than the project's root, you get different binding on extension methods.

using System;

namespace Root
{
    class Program
    {
        public static void Main() => Console.WriteLine(new object().M()); // prints 'Root'
    }
}

namespace Root   { static class E { public static string M(this object o) => nameof(Root);   } }
namespace System { static class E { public static string M(this object o) => nameof(System); } }

Using top-level statements, the same program prints System instead. So a solution to this could be namespace Root;

[333fred]

None of our discussions have included the ability to put the top-level statements themselves in the namespace. Only whether you can put the namespace directive after the statements.

[bbarry]

I think top level statements should always be in the global namespace, regardless of namespace statements in the file. Otherwise you have the issue that top level statements might need to be built into multiple methods if statements after a file level namespace is included:

using System;

Console.WriteLine("Before");

namespace Root;

Console.WriteLine("After");
class Test {}

does that compile to

using System;

class Program
{
    public static void Main()
    {
        Console.WriteLine("Before");
        Console.WriteLine("After");
    }
}
namespace Root { class Test {} }

or (and all the additional complexity this implies)

using System;

class Program
{
    public static void Main()
    {
        Console.WriteLine("Before");
        Root.Continuation.Execute();
    }
}
namespace Root {
    internal static class Continuation
    {
        public static void Execute()
        {
            Console.WriteLine("After");
        }
    }
    class Test {}
}

or is it an error?

[HaloFour]

IMO, it should be an error for any statements to precede a file-scoped namespace directive, top-level or otherwise. Only permit using directives and preprocessor directives. I believe that makes the other questions and concerns moot. It'd be perfectly legal for top-level statements to appear after such a directive and the emitted class can be within that namespace.

[alrz]

None of our discussions have included the ability to put the top-level statements themselves in the namespace.

I'm making the case for that one.

Currently there is no obvious workaround to the issue I demonstrated. Namespace directives could be one. So a possible refactoring could just generate that instead of binding the whole thing to ensure it's safe, and eventually you might not see the option.

On the other hand, if it's done manually (which is exactly what I did) this can easily change the program behavior without the programmer noticing.

I agree with @HaloFour that all the examples using namespace directives anywhere except at the top (maybe before or after imports) does not seem like a good idea and should not be allowed.