-
Notifications
You must be signed in to change notification settings - Fork 484
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
3.0 Roadmap #149
Comments
Hi @mattt, @alejandro-isaza, I was wondering if you could give these proposals a light read some time and provide some short feedback on the proposed changes? (Some of them are rather detailed, so I added a tl;dr where appropriate.) The question basically boils down to: Should I start working on these things on a v3 branch, while we prepare a 2.3 release, or are there items on the list that you would consider not worth following up? And of course feel free to provide proposals of your own if there's additional stuff on your mind for v3, that's not yet covered here. |
@regexident Hey, sorry for not responding sooner. I'll have a chance to review these later tonight. |
Overall, I've very excited about your plans for 3.0, and look forward to your planned changes! Among the non-breaking changes, #143 seems like a clear win, and so does #144 (TIL about the Box–Muller transform — that's really cool!). Of the breaking changes, I think both #121 and #148 are the right changes in the long term, and so long as deprecations are done responsibly, it shouldn't be too bad in the short term, either. I think you're spot on with your overall assessment about code duplication in the library. To that end, I think your proposal in #145 will go a long way to improve things. And I'd even take it a step further and challenge you to consider adopting a code generation approach over what you're proposing in #147: In terms of both performance and comprehensibility, I believe code generation's zero-cost abstraction will be a better solution than a generics-based approach. Since we'd already be incorporating Sorcery for tests in #145, there's no additional cost to use it elsewhere. Do you see any challenges or disadvantages to using code generation to solve out |
They might also make it into a 2.4 release, as they are strictly additive. A separate minor update would also give them more exposure than doing a "CHANGE ALL THE THINGS" 3.0 release with "oh btw, we also added X and Y". 🤔
Yes. The goal would of course be to cause as little trouble as possible during migration.
Funny that I did not think about using Sourcery to generate the functions themselves. It's kinda obvious now. 😄 I'll look into it. 👍
For me the main driver for #147 is for Surge to be compatible with codebases using generic With Swift supporting generics it is mostly straight forward to write one's floating-point arithmetic in a generic way using |
I would like to propose the following (WIP) roadmap of changes for a future 3.0 release:
Code
Non-breaking
Potentially Breaking
Float
/Double
toT: FloatingPoint
Breaking
sqrt
variant with custom output storageOperation
Service Integrations
Bookkeeping
CHANGES.md
fileCONTRIBUTING.md
file.github/PULL_REQUEST_TEMPLATE.md
&.github/ISSUE_TEMPLATE.md
fileThis is a meta issue intended for coordination and tracking of a 3.0 release.
For technical discussions of specific proposals please use the corresponding issue page.
Edit: (Oct 24th, 2019) Added "Operation" section for non-code tasks.
The text was updated successfully, but these errors were encountered: