Discussion: Namespace Level Functions

[dbettin]

I have read the following: https://blogs.msdn.microsoft.com/ericlippert/2009/06/22/why-doesnt-c-implement-top-level-methods/.

But, it is time that C# joins every other modern language (Go, Rust, F#, Kotlin, Swift, ...) and supports top-level functions. The amount of ceremony that goes away with this addition would be fantastic.

Thoughts (and sorry, if I missed an existing issue that is relevant to this one)?

namespace Awesome
{
  void AddToMyList() => MyList.Add(MY_NUMBER + 1);
}

Edited: Removed Top-level variables proposal

[orthoxerox]

👎 for variables, 👍 for functions.

[iam3yal]

@dbettin I think you should break this into two separate issues but I don't think that "free function" is going to happen because you can use using static.

Something like this:

public static class Global
{
    public static void Foo()
    {
    }
}

And then in another place you can just do using static Global; to "import" it.

To global variables I say a big NO.

[thomaseyde]

And then in another place you can just do using static Global; to "import" it.

using static Global; isn't the same at all:

1. There is a communication problem: How will the user know which class to import?
2. For the author there is a naming problem: What to name the class? What if a class is already created for this purpose, but you don't know about it?
3. The user has to import it.
4. The author can add it to global usings, but then the namespace is "lost"; the function is always available, adding noise to intellisense.
5. There are two "module" classes with overlapping function names. You need to import both, but that will not work for the naming collision.

[dbettin]

These are not Global variables. Variables would still be scoped to some container (namespace./module).

Also, yes, this is possible today with static methods. But, imagine how clean this approach is compared to always creating public static classes/methods.

[svick]

In practice, what's the difference between a member that's directly in a namespace and a member of a static class in the global namespace?

In other words:

using System.Collections.Generic;

namespace Awesome
{
    const int MY_NUMBER = 5;
    List<string> MyList = new List<string>();

    void AddToMyList() => MyList.Add(MY_NUMBER + 1);
}

vs.

using System.Collections.Generic;

static class Awesome
{
    public const int MY_NUMBER = 5;
    public static List<string> MyList = new List<string>();

    public static void AddToMyList() => MyList.Add(MY_NUMBER + 1);
}

Is the main difference that you don't have to write public static everywhere?

[iam3yal]

@dbettin

These are not Global variables. Variables would still be scoped to some container (namespace./module).

I really don't know what you're asking then and @svick already said what I was about to say so really, not sure about the differences except keywords and the "plumbing" work that almost doesn't exist and in practice is a very, very small price to pay. :)

[dbettin]

I am looking for a discussion around the inclusion of functions not methods into C#.

As C# continues to evolve into a dual purpose language (records, pattern matching, discrimated unions; to name a few), functions are a key abstraction for the functional side of the language. There is a reason why Go, Rust and Kotlin have them as part of their respective languages.

Just look at extension methods as you will see the nonsense that is the "static class wrapper". Or any static class that only contains methods. Why not make the language less ceremonial? C# has made existing features less verbose in the past and because of that, has given us a better language to read and write.

[dbettin]

Changed the title so people can focus the discussion on functions only.

[dbettin]

You are speaking to the user of these methods. I am specifically talking about the author and/or reader of the extension methods.

[Joe4evr]

[dbettin]

The "and" is the that it doesn't address the critique of extension methods wrapped in a static class. My critique is in reference to how you author them not in how you use them.

[ramoneeza]

I think is better Idea to include a "Module Initialization" to an assembly as DELPHI does.

[DavidArno]

@svick,

Is the main difference that you don't have to write public static everywhere?

Even if we did go for namespace-level functions, I'd still want them to be private by default, so public would be required. So really, this only saves on the use of static.

[GeirGrusom]

I think this would remove a lot of needs for static.

namespace FooApplication
{
  using static System.Console;
  void Main() => WriteLine("Hello World!");
}

I think this would be great because usually the Program class ends up just being a shim for other bootstrapping classes like WPF or Avalonia's Application class.

[MkazemAkhgary]

No. Static class itself groups set of extension methods and helper functions. Its not going to save you anything but allowing you to make a pile of extensions all over the place.

Also in c# 8 there is going to be better support for extension methods and i think this proposal doesnt fit with that really well.

[whoisj]

I think this would be great because usually the Program class ends up just being a shim for other bootstrapping classes like WPF or Avalonia's Application class.

Agreed. It has always confounded me that the Program() ctor gets invoked before the external call to Program.Main(string[]) because reasons. I understand those reasons, but it is yet another reason why C# (NetFx in general) can never be a foundation language like C is today.

[svick]

@Richiban All those are fairly small syntactical changes. I don't see how introducing a whole new concept of "module" would be worth that.

[Richiban]

@svick

All those are fairly small syntactical changes

Absolutely they are small changes but, I think, important ones. They should also make it relatively easy to implement. Having free functions in the language seems to be something we want and F#-style modules are by far the easiest way to get them.

[Joe4evr]

I think we should follow F#'s approach and allow you to define a 'module' (essentially just a static class that looks just like a namespace in terms of how it's used).

So what you're saying is you want VB.

[Richiban]

@Joe4evr

So what you're saying is you want VB.

I wouldn't call it VB, exactly.

[DavidArno]

@Joe4evr,

Ha, if even VB.Net has modules, there's no real excuse not to provide them in C# too 🤣

[aka-nse]

As you know, CIL supports global functions and in C# they appears as members of <module> class (and there is no way to call them except through reflection).

Just in case, note that namespace scooped function may provide slight interoperability for other .Net family but module won't (although it is doubtful that such languages exist).

[jnm2]

CIL supports global functions

Wait, really? I've been using the CIL reader API for a while and don't know how that would even work without a CIL class.

[svick]

@jnm2

CIL supports global functions

Wait, really? I've been using the CIL reader API for a while and don't know how that would even work without a CIL class.

As far as I can tell, the answer is "kind of".

ECMA-335 §II.10.8 Global fields and methods explains how global members are represented as members of the special class <Module>. It is special in that it's a class that doesn't have a base class (the only other class like that is System.Object) and has special handling when multiple <Module> classes are defined in modules of the same assembly.

But if you're reading the IL, it looks almost like any other class.

[Richiban]

@DavidArno

I'm curious about this statement of yours:

Even if we did go for namespace-level functions, I'd still want them to be private by default

I'm struggling to imagine what it means for something to be private within a namespace. I think that would be a new concept for C#: currently this is not legal:

namespace MyNamespace
{
    private class Foo
    {
    
    }
}

Even if it was legal, what does it mean? That members and types defined in MyNamespace are only visible from members and types that are also defined in this namespace? Or only in the same file?

[DavidArno]

@Richiban,

I could simply be confused of course, but my thinking was that even for namespace-level functions, or module-based functions, they still end up being lowered to static methods in some class (which could be <Module>, though I've never heard of that special class before, so know nothing about it). Thus they can be private.

For any set of free functions, I'd want some of them to be implementation details (ie, private). Since the default behaviour is for functions/methods to be private unless annotated otherwise, then it makes sense to me (until persuaded otherwise, of course) that free functions should default to private, too.

[Richiban]

@DavidArno

even for namespace-level functions, or module-based functions, they still end up being lowered to static methods in some class

This is true, and therefore your suggestion makes sense, but I would actually be in favour of hiding this from the user. I would want it look and feel, as much as possible, like the functions actually just exist on their own in a namespace.

As for implementation details, we still have local functions which will solve the majority of cases.

I'm open to having my mind changed on this one, since even F# allows private values in modules:

module Stuff =
    let mutable private state = 0
    
    let f() =
        let result = sprintf "%A" state
        
        state <- state + 1
        
        result
    
open Stuff

f() |> printfn "%A"
f() |> printfn "%A"
f() |> printfn "%A"
f() |> printfn "%A"

I still think though that the default should be public. I know that in C# classes the default is public, but let-bindings are private in F# classes but public in modules and everyone seems to cope just fine. C# is also introducing default interface methods and in interfaces members are public by default†, so there's precedent.

† I haven't had a chance to play with the default interfaces feature yet; is the public keyword going to be allowed on interface members now?

[Thaina]

I support this idea. Wish we could write the actual only one void Main

[yaakov-h]

@Thaina You could still have two within an assembly if you have two namespaces 😉

[Thaina]

@yaakov-h Well then I think we should let us just write it without namespace and make it default namespace

[bukowa]

Hey is there any progress here?

[HaloFour]

The language team hasn't expressed any interest in pursuing this beyond what was already shipped with top-level statements. Until a member of the language team wishes to champion some kind of design for a feature here, there will be no progress.