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.

[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]

@whoisj Would you say the same thing about C++, since global variable initializers execute before main() there?

[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.

[bernd5]

Today you can define "global functions like":

global using static GlobalFunctions;
using System;

public static partial class GlobalFunctions{
    public static void SayHello(){
        Console.WriteLine("Hello");
    }
}

And use it directly e.g.:

SayHello();

I personally see no need to extend this further - I may agree that the declaration of a "global function container" seems not needed but it helps to avoid name clashes and global namespace pollution.

[CyrusNajmabadi]

@aradalvand please tone down your language. You're above posts are getting far too hostile and run afoul of the .net code of conduct.

Please remember to be civil and to treat people with respect. Thanks! :-)

[tannergooding]

There's a broader consideration over just typing convenience here as well.

The global namespace is in fact global and exposing members here can trivially lead to conflicts, versioning issues, and other long term problems. It is one of the reasons that namespaces and types were introduced into programming, to solve the problem of pollution, and why many modern languages have accordingly decided that exposing global functions is a bad idea and have explicitly opted to never provide such support in the first place.

It is trivial, on the other hand, to define a class to encapsulate your general helper or utility functions, it is even trivial to define a global using in the same file if you want them to be globally visible to your project. This gives you the equivalent functionality without the language needing to churn and without the need for introducing new types of overload resolution problems into C# at the public API surface level.

This isn't a simple ask, as much as it initially seems like one. It isn't something that is trivial to provide and it isn't as contention free as one might assume. It is largely an anti-pattern that would come with immediate guidance to never use in public API surface and which would likely need a corresponding analyzer or language feature to block its use across assembly boundaries.

[bukowa]

Maybe if namespace would be a normal static object?

[aradalvand]

@tannergooding You're arguing against global functions; this issue/discussion is asking for namespace-level functions that allow you to not have to have a dummy wrapper class if all you want to declare is a function; those are two very different things.

[tannergooding]

They are very related concepts with many of the same issues and would result in the same general guidance of "don't do this, especially in public API surface".

It's worth noting that that, as is frequently cited, language feature asks effectively start at -100 points and need to reach +100 points to be clearly worth implementing. Features that have trivial workarounds, which are unlikely to be broadly used, which do not provide clear benefit (at least in the face of the downsides it also brings), which violate common design practices/guidelines, and so on are not likely to move the needle far enough to get championed, discussed and passed through LDM, and finally implemented. This is particularly true in the face of all the other potential features that the language team could work on instead.

You're more than welcome to continue wanting this feature and to continue discussing and providing examples of where it does have merits, but I expect this is one of those features that is effectively in the camp of "likely never" (noting I'm not on the language design team, just giving my input on where I'd expect this to land in practice given the input/discussion so far and the general consideration given to other features/asks) and which you'd be better off just writing the precisely 4 lines of code the rare handful of times this comes up.

[En3Tho]

@aradalvand I don't think that your examples are in the same ballpark as this one. primary constructors, file-scoped namespaces, top-level statements - these are used all the time by all C# users (well, I believe most of them are using those).

Examples you've given are saving these few braces and an indentation level per file for everybody using the language. That's a lot of braces and indentation levels. It maybe seem small but benefit is muptiplied greatly.

I'm not sure this one is ever going to be as useful pr influential as in "wow, we've got file-scoped namespaces let's use this EVERYWHERE`

And one more thing - these features don't introduce weird naming clashes and overload priority issues simply by using namespace.