- "I see a big tropical void where [redacted's] face was... It's so annoying"
- "It's so cold here, it's 70 [F]"
Today, we looked at some of the details around this feature, specifically what should be supported before or after a top-level namespace declaration. The proposal as written allows only extern aliases, using directives, and global attributes. The proposal also does not allow multiple top-level namespaces: you can only have one in the file, and all following type declarations are considered to be part of that namespace. The debate, therefore, centers on whether we allow multiple of these declarations in a file, what they would mean in that case, and whether we allow a top-level namespace at the same file as top-level statements.
In many ways, this seems like a style question. Syntactically, regardless of whether allow these concepts to be mixed/duplicated
in a single file in the formal grammar, the compiler will have to implement rules for what this means in order to provide a good
IDE experience. There is potential value is allowing this to be flexible, as we generally do not take strong stances on syntax
formatting guidelines beyond the default rules shipped with Roslyn, and those are very customizable to allow users to decide
whether to allow them or not (var vs explicit type has 3 major doctrines, for example). By allowing all forms here, we would
let users decide what is preferred to them and what is not.
That being said, however, we have concerns that we even understand what code like this would do:
namespace X;
class A {}
namespace Y;
class B {}For this scenario, some people would expect these types to be X.A and Y.B, while others would expect them to be X.A and
X.Y.B. We have additional concerns around how this type of code would read in the presence of top-level statements, and
whether there would be enough visual contrast between the end of the top-level statements, the namespace, and then types under
the namespace, or whether that would be confusing to read. If we restrict the usage now, nothing would stop us from loosening
restrictions in a later language version if we discover that we were too restrictive initially, but if we let the genie out of
the bottle now, we can never put it back in.
No conclusion today. We're largely split between these two extremes, allowing everything or allowing nothing. We'll take this back up again soon to finish debate and settle on a conclusion.