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

3.0 Roadmap #149

Open
11 tasks
regexident opened this issue Oct 13, 2019 · 4 comments
Open
11 tasks

3.0 Roadmap #149

regexident opened this issue Oct 13, 2019 · 4 comments

Comments

@regexident
Copy link
Collaborator

regexident commented Oct 13, 2019

I would like to propose the following (WIP) roadmap of changes for a future 3.0 release:

Code

Non-breaking

Potentially Breaking

Breaking

Operation

Service Integrations

  • Add CodeCov integration? (free for open source)
  • Add CodeClimate integration? (free for open source)

Bookkeeping

  • Add CHANGES.md file
  • Add CONTRIBUTING.md file
  • Add .github/PULL_REQUEST_TEMPLATE.md & .github/ISSUE_TEMPLATE.md file

This 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.

@regexident
Copy link
Collaborator Author

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.

@mattt
Copy link
Collaborator

mattt commented Oct 22, 2019

@regexident Hey, sorry for not responding sooner. I'll have a chance to review these later tonight.

@mattt
Copy link
Collaborator

mattt commented Oct 23, 2019

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 Float / Double conundrum?

@regexident
Copy link
Collaborator Author

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!).

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". 🤔

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.

Yes. The goal would of course be to cause as little trouble as possible during migration.

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:

Funny that I did not think about using Sourcery to generate the functions themselves. It's kinda obvious now. 😄 I'll look into it. 👍

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 Float / Double conundrum?

For me the main driver for #147 is for Surge to be compatible with codebases using generic T: FloatingPoint.

With Swift supporting generics it is mostly straight forward to write one's floating-point arithmetic in a generic way using T: FloatingPoint. Right now however one has to pick: make it generic, or make it performant (via Surge). So why not both? 🙃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants