To reduce bloat for every developer, we should provide "literal extension methods" in a separate namespace, instead of the global CoreLibrary namespace. This is important because we do not want every developer to have all extensions on non-corelib-owned types. For example, without this, when a dev types 1. in an IDE, the list of autocompletes would contain all our custom unit constructors, potentially annoying the developer or hiding important features.
The remaining question is: put all literal extension methods into one namespace CoreLibrary.LiteralExtensions or separate them into multiple imports in order to keep autocomplete lists clean? (CoreLibary.Length, CoreLibrary.Duration)
This concerns issues #40 and #35.
To reduce bloat for every developer, we should provide "literal extension methods" in a separate namespace, instead of the global
CoreLibrarynamespace. This is important because we do not want every developer to have all extensions on non-corelib-owned types. For example, without this, when a dev types1.in an IDE, the list of autocompletes would contain all our custom unit constructors, potentially annoying the developer or hiding important features.The remaining question is: put all literal extension methods into one namespace
CoreLibrary.LiteralExtensionsor separate them into multiple imports in order to keep autocomplete lists clean? (CoreLibary.Length,CoreLibrary.Duration)