GRDB 7.x seems to lose short-form functions (Sendability)

[freak4pc]

Hey there,
I'm unsure if this is a GRDB thing, which is why I opened as a discussion :)

I'm trying to GRDB 7 beta and noticed that we have to "open" the expression of functions that implicitly take the first-argument, i.e. this change is forced, or I get an issue in regards to function sendability:

Converting non-sendable function value to '@sendable (Database) throws -> Entity?' may introduce data races

This is the change I have to make now and it will be extremely wide to do this everywhere. Wondering if any simple way around it:

-let hasEntities = (try? self?.database.read(Entity.fetchOne)) != nil
+let hasEntities = (try? self?.database.read { try Entity.fetchOne($0) }) != nil

[groue]

Hello @freak4pc :-)

This can be fixed by instructing the compiler to stop with the InferSendableFromCaptures flag :-) See Shorthand Closure Notation in the "Swift Concurrency and GRDB" guide.

[groue]

You're welcome :-)

[freak4pc]

I had another question about why DatabaseValueConvertible isn't Sendable - should I open a new discussion? Issue? I'm not sure what's the right format to not overflood with question :D

[groue]

It is not Sendable because sendability is not required for performing database value conversions. This helps legacy types like NSData (arguably not much used any longer) to participate, as well as non-sendable user types. Gods know what people are able to come up with, or forced to deal with.

Sendable is not an easy protocol to conform to, and one should not use @unchecked Sendable lightly, especially on types they do not own. That's why the library prefers to avoid requiring sendability when possible. GRDB will require less Sendable conformances as time passes and Swift concurrency skills grow, not more.

If the fact that DatabaseValueConvertible does not imply Sendable creates troubles in your code base, then yes, please open a new discussion. This will help other people finding it. We will not make DatabaseValueConvertible imply Sendable, but we'll probably figure out how to solve your issue in another way.

[freak4pc]

Yeah I imagined that's the issue. Basically we had some helper funcs that take a [Column: DatabaseValueConvertible] to update, but I switched it to [Column: any Sendable & DatabaseValueConvertible] and that seems to work :) Hopefully it's "The right thing" ™️

[groue]

It does not look wrong, which is a good start ;)

GRDB converts all DatabaseValueConvertible into a DatabaseValue whenever it wants to store them inside a Sendable type:

// Not Sendable
let data: NSData = ...

// Sendable
let request = Player.filter(someColumn == data)

You could follow the same technique and replace the dictionary with [Column: DatabaseValue].

Now, this may force many places in your app to perform an explicit call to databaseValue, and this would not be very ergonomic:

 // Meh
-dict[column] = "foo"
+dict[column] = "foo".databaseValue

In this case the dictionary of any Sendable & DatabaseValueConvertible would be arguably superior.

Finally you could also question the implicit premise, i.e. wonder if the dictionary really needs to be Sendable itself ;)

Swift concurrency really makes it difficult to perform local reasoning - frequently one needs to have the full picture in order to make a decision...