While I could agree with you about those "!" "?"

then definitely disagree about implicit using or file scoped namespaces

There's nothing new in terms of keywords about them, concept itself very simple

and makes code more readable and shorter, that's it.

It's just: "hey, some namespaces are very, very popular - let's make it this way, that you don't have to include them everywhere"

and "hey, why every code is one level indented if everyone is using one namespace per file anyway?"

> hey, why every code is one level indented if everyone is using one namespace per file anyway?

I would even take it 1 step further. Specify the class name at the top of the file, 0 indentation for functions.

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

What draw backs are there? I can't think of any beyond the initial WTF factor of seeing functions living free of braces {} prison.

Multiple classes per file with would still be an option of course.

Namespaces allow for logical grouping

How would you group things without namespaces?

by their physical location?

No, by their namespace. Never suggested removing namespaces or classes. Just removing the "indentation".

> 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 v5, is now legal in v6, then yes we honestly can and must call it that.

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.

What you're describing sounds a lot like Deno (or at least where Deno is headed):

https://deno.land/[email protected]/tools/compiler