3 ms·

That was an experiment the team didn’t end up committing to - it’s been backed out. That said it was a fascinating dive into the flexibility of Swift, and the K

• pjmlp 1y ago
  Interesting, thanks for sharing, is there a rationale somewhere? As someone that enjoys using C++ despite all its warts, I can imagine a few reasons, but would nonetheless an interesting read, in case that is public. I guess that experience might also had an impact on ongoing Swift 6+ features.
  • TobbenTM 1y ago
    The Ladybird project started a similar journey, and indeed they are mainly waiting on Swift 6+ features as documented in their blockers issue: https://github.com/LadybirdBrowser/ladybird/issues/933 https://github.com/LadybirdBrowser/ladybird/issues/933
  • jen20 1y ago
    I don’t know the specific reasons (and the pull request referenced in the merge commit appears to have been deleted), but my guess is that the extra complexity vs using modern C++ features was not worthwhile to the core FDB team.
    • pjmlp 1y ago
      Which could be a good reasoning, assuming it is being enforced somehow, in regards to modern best practices, which is usually the main issue.
      • jen20 1y ago
        Indeed - my guess is that there is a policy of "improve things as you touch that area of the codebase" rather than blanket rewriting of working code going on.
• dwaite 1y ago
  It was then backed back in? https://github.com/apple/foundationdb/commit/6cd5ad2ffe1d246e695bb51d0184e74d9bac7217 https://github.com/apple/foundationdb/commit/6cd5ad2ffe1d246...
  • jen20 1y ago
    Huh, apparently so! It doesn't seem like much has happened since - there certainly aren't many pull requests which reference Swift [0] since it was restored. [0]: https://github.com/apple/foundationdb/pulls?q=is%3Apr+swift https://github.com/apple/foundationdb/pulls?q=is%3Apr+swift