Agree about immutability (I would love to have “readonly” to be applicable to classes), but I like the current static classes approach.
It’s a single keyword, the language guarantee you won’t have any instance fields or methods in these classes.
Global functions pollute namespaces, and auto-complete index. Static classes provide local namespaces for these functions, they also hide implementation details. I sometimes implement moderately complex pieces of functionality as a static class with just a single public method, the rest of the code is in private methods. These private methods don’t show in auto-complete in outside code, even if they’re extension methods. If such class grows too large for a single source file, C# has partial classes.
It's a good point about auto-complete I hadn't considered, maybe globals could have some obvious name thing going on, I hate this suggestion but for example an underscore prefix.
Some examples of where global functions might make sense, the Main function of a console application doesn't need to be in a class, or the general Utils and Helpers approach soon becomes cumbersome, you end up having to name things that don't really need names. While static classes can help organise these global functions you also end up playing the naming game when you don't need to. It might not be any improvement but it's an interesting thought exercise to imagine functions living in just a namespace, not a class.
I think in C# static still doesn't give you enough guarantees at either the class or member level. A static class can still have public static mutable members which is a horrible code smell. C# contains enough flexibility to do the things I want, e.g. make things static and readonly, but it's a lot of additional typing and I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo` which I remember having seen in other places (F#?).
> you end up having to name things that don't really need names.
Strictly speaking namespaces don’t need names, either. But for medium to large projects they’re still useful, and enforced by the IDE.
> to imagine functions living in just a namespace, not a class.
You can place them into a namespace on the consumer side of the API, with `using static`. While not the same, might be good enough in practice: you normally have multiple `using` statements on top, for namespaces.
> I'd be interested in seeing the model reversed, e.g. immutable defaults with something like `public mutable class Foo`
I wouldn’t want immutable defaults, but I do want readonly classes and structures, with readonly being part of the type system.
BTW, the new value tuples with named fields is a step in the right direction https://blogs.msdn.microsoft.com/mazhou/2017/05/26/c-7-serie... Useful but limited, I would prefer real immutable classes & structures. Currently I have to create them manually, mark all fields public readonly, implement the constructor, that’s more typing than I’d like.
It’s a single keyword, the language guarantee you won’t have any instance fields or methods in these classes.
Global functions pollute namespaces, and auto-complete index. Static classes provide local namespaces for these functions, they also hide implementation details. I sometimes implement moderately complex pieces of functionality as a static class with just a single public method, the rest of the code is in private methods. These private methods don’t show in auto-complete in outside code, even if they’re extension methods. If such class grows too large for a single source file, C# has partial classes.