Thank you for including metatype conformances! Will that be implemented in a way that make it easier to allow metatypes to conform to Hashable as well in a follow on proposal?
As such, the compiler rejects conformance of structs and enums to the ConcurrentValue protocol when one of their members (or associated values) does not itself conform to ConcurrentValue (or is known to conform to ConcurrentValue through a generic constraint)
Should that say "or is not known to conform to ConcurrentValue through a generic constraint"?
@concurrent
The purpose of @concurrent is to support function values that conform to ConcurrentValue and can therefore be used in contexts that require ConcurrentValue. The attribute-based design feels somewhat ad-hoc and not scalable. For example, we have discussed function values that could conform to Equatable (using equatable captures combined with source identity).
How would additional protocols fit into the current design? Would we introduce new attributes every time we want function values that have a new conformance (for example, an @equatable)?
I'm wondering if you have considered a more general approach. The immediate option that comes to mind is to use an @ConcurrentValue attribute on the function. This would allow @Equatable, @Hashable, and any other conformances that could make sense in the future.