5 ms·

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 keywo

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?" It just simplifies stuff, can we honestly call it an expansion of language?

foobarbaz33 4y ago
> 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.
- Kwpolska 4y ago
  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.
  - SideburnsOfDoom 4y ago
    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.
    - Kwpolska 4y ago
      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).
      - foobarbaz33 4y ago
        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.
- tester756 4y ago
  Namespaces allow for logical grouping How would you group things without namespaces? by their physical location?
  - foobarbaz33 4y ago
    No, by their namespace. Never suggested removing namespaces or classes. Just removing the "indentation".
SideburnsOfDoom 4y ago
> 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.

foobarbaz33 4y ago

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

Kwpolska 4y ago
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.
- SideburnsOfDoom 4y ago
  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.
  - Kwpolska 4y ago
    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).
    - foobarbaz33 4y ago
      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.
tester756 4y ago
Namespaces allow for logical grouping How would you group things without namespaces? by their physical location?
- foobarbaz33 4y ago
  No, by their namespace. Never suggested removing namespaces or classes. Just removing the "indentation".

SideburnsOfDoom 4y ago

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