Rewrite in Swift, and then have an ObjC wrapper?

[ccgus]

I wonder how hard this would be?

[groue]

That's funny, I had to build GRDBObjc in order to provide an FMDB compatibility layer to GRDB, for apps with legacy ObjC code.

[ccgus]

Oh, I should check that out when I get around to it.

[groue]

It's no longer maintained, so I wouldn't bet on its usefulness. But I like stories of convergent evolution :-)

[robertmryan]

A literal Swift conversion would probably not too bad.

But the interesting question in my mind is the “queue” pattern, which currently is an inherently synchronous implementation. At the minimum, I’d vote for no synchronous API and only asynchronous renditions in FMDB 3.0. And I’d suggest Combine publishers for Swift developers. (In Combine projects, wrapping closure based API in futures feels distinctly anachronistic.)

I’d be inclined to see what comes out in WWDC 2021, too, as that might color our thoughts about about what the appropriate asynchronous patterns are going forward. I’m intrigued to hear their thoughts are, esp in light of the new async patterns in Swift 5.5.

[ccgus]

I'd want both async and sync operations personally. And Combine stuff would make sense too.

And waiting till the next WWDC seems fine, I'm in no rush :)

[tokyovigilante]

I wonder how hard this would be?

Not very, just time-consuming. I've been working on a roughly 1:1 port to Swift for a Linux project, where Obj-C is not available. It is very incomplete but should be easy to see where the gaps are.

I haven't looked at macOS compatibility/portability as I'm not using that platform, but the code has no additional dependencies beyond SQLite itself.

[mecoFarid]

I'd want both async and sync operations personally. And Combine stuff would make sense too.

And waiting till the next WWDC seems fine, I'm in no rush :)

We are, haha

[lzcuriosity]

您的邮件已经收到，我会尽快查阅，谢谢！Best Wishes!