-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename Complex type or module #94
Comments
More generally, I would like to establish a general policy for how to handle this situation, as I expect it to come up repeatedly in Swift Numerics. |
My vote is for renaming the module. There is little precedent for appending |
I think that it would make more sense to rename the module, since one is more likely to spell out the type more often (especially if one is writing generic code), and so having |
@xwu That's basically my feeling as well (but: |
I also think renaming the modules is better, especially if they will migrate into the standard library.
|
Draft PR using "Numerics" as a placeholder module prefix here: #97 |
Resolved in 0.0.5 by adding the disambiguating Module suffix to Real and Complex. |
For the reasons discussed in this forums thread it would be slightly advantageous to make the Complex type and module have different names. This requires renaming one of them.
This would allow people who want to work with a single concrete complex type to do something like:
They would then still be able to get at the generic type as either
ComplexType
orComplexModule.Complex
.As you can see, renaming the type makes this specific use case a tiny bit neater, but makes the normal generic usage a tiny bit messier (while renaming the module only changes the import statement in routine use, which is less invasive).
The text was updated successfully, but these errors were encountered: