> There's nothing new in terms of keywords about (implicit using or file scoped namespaces)
And I didn't imply that they were new keywords, they were examples of the second category, "new ways of doing things". The text "do the same thing" alludes to that.
> and makes code more readable and shorter, that's it.
Correct, but each new ways of doing things comes at the cost of there now being (at least) two ways to do the same thing.
> It just simplifies stuff, can we honestly call it an expansion of language?
If a source file that was not legal in language version 9, is now legal in language version 10, then yes we honestly can and must call it that. It is literally an expansion of the subset of all possible source files, that are legal source files in the language.
Does it "simplify stuff" if there are now 2 ways of doing a thing, when previously there was only one? The parser has to deal with both now. It depends on how you look at it, I think. e.g. It depends on if your code mixes them. If not then the code can be simpler, but as coders we have to still know both as we might encounter both.
C# does not mandate having one class per file. (Java doesn’t for non-public classes either.) While I suppose many (most?) devs/projects have adopted this rule, there are cases where it makes more sense to keep related stuff in one file.
C# also did not mandate having one namespace per file. Devs have adopted a "one namespace per file" rule because it's generally a good idea. So now the new "file scoped namespaces" allows only 1 namespace per file; and if you want more than that, well then your namespace can't be file-scoped, by definition. You can still use namespaces with { } in that case.
The same _could_ be done with type declaration such as classes and interfaces. If it would be beneficial idea is another thing.
Sure, but “one namespace per file” is a much more obvious idea than “one class per file” (especially with C# IDEs aggressively tying namespaces to the filesystem layout).
I programmed in C# for roughly the first 15 years of my career. Then, Ruby, Go, TypeScript. Going back to C#, it does feel bloated. It’s accreted a lot more complexity since I stopped using it (just before .Net Core).
I’d love to have a TypeScript language with the standard library, single binary output, and build speed of Go.
100% true, it is. More keywords in each release. More ways to do things.
e.g. Now we use "record" and "with" keywords, and operators such as "a!.b" or "a?.b" .
And we set projects up with "implicit usings", and "file-scoped namespaces" which do the same thing will less indenting.
While I like all of these, the downside is yes, it's an ever-expanding language.