3.0 Roadmap

[regexident]

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

Code

Non-breaking

• Auto-generate unit tests & benchmarks
• Efficient randomized initializers for Array/Vector/Matrix
• Efficient non-allocating column/row-based Matrix iterators

Potentially Breaking

• Migrate from Float/Double to T: FloatingPoint

Breaking

• Migrate API to a more idiomatic naming scheme
• Deprecation/Removal of sqrt variant with custom output storage

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]

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]

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

[mattt]

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]

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? 🙃