Enable name lookup for modules by suffixing Module when needed to break ambiguity.

[stephentyrone]

In particular, the following module renames are applied:

• Real -> RealModule
• Complex -> ComplexModule

This is a source-breaking change, if you currently directly import these modules. (sorry!)
The fix is to either import Numerics instead, or to use the new, suffixed, names. The good news is that fixing this should require only a straightforward search-and-replace for anyone affected.

Some context for why I'm making this change can be found here. There are a few other use patterns that are enabled by this change, all tied into the same name lookup issue.

[rxwei]

Would "Numerics" as a suffix ("ComplexNumerics" and "RealNumerics") read more natural?

[stephentyrone]

I think so, but it would be less closely in line with NIO. Worth discussing! I think there's a few good options including a three-char prefix, and the suffix that's literally just "module" (this might work better with things like "ShapedArray". I slightly prefer "ShapedArrayModule" to "ShapedArrayNumerics".)

[SusanDoggie]

Um... i think putting an underscore in the middle is not swifty. I've never seen a project named like this.

[stephentyrone]

Um... i think putting an underscore in the middle is not swifty. I've never seen a project named like this.

https://github.com/apple/swift-standard-library-preview

In particular, SEnnnn_FeatureName maps fairly closely. I'm not dead-set on using the underscore, but right now it seems like maybe the best of a not-great set of options. Ideally this wouldn't be necessary at all, but the compiler limitations of having a module and type with the same name are a real concern.

Basically, here are the possibilities I've considered:

1. NumericsAaaaaBbbbb
2. NumAaaaaBbbbb
3. NUMAaaaaBbbbb
4. Numerics_AaaaaBbbbb
5. AaaaaBbbbbNumerics
6. AaaaaBbbbbModule

(3) is arguably the most "swifty", in that the majority of swift code written to date is for Apple platforms and mostly-follows Objective-C prefix conventions.

(1) and (2) are good because they avoid abbreviations, but they don't do a good job of differentiating between the prefix and the "base" module name.

(4) is explicit and makes clear that Numerics is a separate thing from the module name. For me, that makes it the most "swifty"--favoring clarity and readability over style concerns.

(5) is probably a little too cute. It works great with Real and Complex, but may not work well as we add more modules (ShapedArrayNumerics? IntegerUtilititesNumerics?). It's also conceptually "backwards" compared to the scoping.

(6) is fairly attractive to me, because it's also very clear what's going on, and we could also adopt the rule that you only need to have the suffix when there's a clash to be avoided. So we would have e.g. RealModule and ComplexModule, but IntegerUtilities. Actually, writing this up, I'm talking myself back around to this option.

[SusanDoggie]

Is it possible to use "Num" as a prefix?

• NumComplex
• NumReal

[xwu]

(6) is fairly attractive to me, because it's also very clear what's going on, and we could also adopt the rule that you only need to have the suffix when there's a clash to be avoided. So we would have e.g. RealModule and ComplexModule, but IntegerUtilities. Actually, writing this up, I'm talking myself back around to this option.

I like that option; it's like how we have a rule about Protocol as a disambiguating suffix, but for modules.

[stephentyrone]

I like that option; it's like how we have a rule about Protocol as a disambiguating suffix, but for modules.

Yeah, this seems like the best approach to me now.