Skip to content
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

Closed
stephentyrone opened this issue Jan 21, 2020 · 7 comments
Closed

Rename Complex type or module #94

stephentyrone opened this issue Jan 21, 2020 · 7 comments
Labels
policy question Further information is requested

Comments

@stephentyrone
Copy link
Member

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:

typealias Complex = ComplexType<Float> // if we rename the type
typealias Complex = ComplexModule.Complex<Float> // If we rename the module

They would then still be able to get at the generic type as either ComplexType or ComplexModule.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).

@stephentyrone stephentyrone added policy question Further information is requested labels Jan 21, 2020
@stephentyrone
Copy link
Member Author

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.

@xwu
Copy link
Contributor

xwu commented Jan 21, 2020

My vote is for renaming the module. There is little precedent for appending Type at the end of names for generic types, but plenty of precedent for seeking out unique module names, which are essentially not at all constrained by naming guidelines.

@varungandhi-apple
Copy link

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 ComplexType<..> in many places makes it a little tedious to skim.

@stephentyrone
Copy link
Member Author

stephentyrone commented Jan 22, 2020

@xwu That's basically my feeling as well (but: Type is purely a strawman suffix here; if someone had a good proposal for a suffix that made more sense, I would consider it).

@benrimmington
Copy link
Contributor

I also think renaming the modules is better, especially if they will migrate into the standard library.

  1. You could use a three letter prefix (similar to the SwiftNIO modules):

    import Numerics
    import NMXBigInt   // struct BigInt
    import NMXComplex  // struct Complex
    import NMXReal     // protocol Real
  2. You could use the "Swift" prefix:

    import SwiftNumerics
    import SwiftBigInt   // struct BigInt
    import SwiftComplex  // struct Complex
    import SwiftReal     // protocol Real

@stephentyrone
Copy link
Member Author

stephentyrone commented Jan 24, 2020

Draft PR using "Numerics" as a placeholder module prefix here: #97

@stephentyrone
Copy link
Member Author

Resolved in 0.0.5 by adding the disambiguating Module suffix to Real and Complex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
policy question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants