Please introduce namespaces in the language

[lafrank]

Adding the concept of namespaces (like they exist in C#) would ensure a abstraction layer to the code and would help to decouple file system structure from logical code structure. Given that, the code would be independent of the folder structure which would help portability.

Having namespaces implemented would also greatly reduce the complexity and burder of managing the import / export statements that also occurs and forms a bottleneck in Python.

Given namespaces (above and beyond other advantages) a Flutter project could then potentially have a project or solution file (see Visual Studio projects) and then imports / exports could focues on namespaces instead of folder structures.

Please don't throw this idea away. For such a great a modern language like dart this would be a highly desirable productivity feature.

[lrhn]

C# has a cross-file global namespace that all declarations belong to.
Dart does not. A Day library does not introduce members into any global namespace automatically, you have to import the library in order to access it's members.
That is unlikely to change, which means that we can't just add C# namespaces verbatim to Dart. Namespaces in Dart will have to be a distinct, but similar, feature, and we'll have to say how it works.

The closest thing would probably be:

Libraries can declare namespaces as top level members, and as members of other namespaces.

namespace someIdentifier {
  // declarations
}

Other existing top-level declarations can also be declared inside I namespace, including imports and exports.
A new 'using' <qualifiedIdentifier> <showOrHideClause> ';' is allowed in the same place as imports, and as a using <qualifiedIdentifier> on imports and exports, which opens that namespace as accessible in the current namespace scope. Parts are included in the namespace where the part directive occurs.

The namespaces (unless named with a library private name) are exported names, part of the export scope of the library. They are names in a scope just like any other name, and mustn't conflict with a non-namespace name.

If two namespaces with the same name are introduced as members of the same namespace, by importing or using, any name they both introduce is conflicted, just like conflicted imported names today - it's only an error of code refers to that name.
If a namespace is declared with the same name as an imported namespace, any members in the current file's namespace declaration take precedence over imported names, just like current declarations take precedence over imported names in the library's to level scope.

Prefixed imports, import "..." as prefix;, are almost equivalent to

namespace prefix {
  import "...";
}

except that the as prefix introduces a namespace that is not exported, it's a local namespace only, as if it had a library private name.
The syntax can stay valid, and generalized to as <qualified mIdentifier>, but will probably introduce public exported namespaces unless the identifies are library private.
It'll require a migration to convert an existing prefixes to private names to preserve the current behavior.

The show and hide modifiers will also be allowed to have qualified identifiers in the list, to show or hide individual namespaced declarations. Might even be allowed something like show ns1.{foo, bar} to show only ns1.foo and ns1.bar, and show ns1.{hide baz} to show (only) everything in ns1 except ns1.baz.

In short: I see zero chance of making Dart scopes be "independent of the file system". Libraries are units of import, and exports, and libraries are identified by a single file. Having a solution file that defines the files of the program, and files themselves not needing to have imports, is a content different direction, and not one I expect Dart to take without it providing a significant benefit.

What namespaces can do is to stratify the names exported by a library into a hierarchical structure, which can allow multiple declarations with the same name, as long as they are in different namespaces.