You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add conditional conformance to the @Element property wrapper to the ExpressibleBy___Literal Swift Standard Library protocols similar to the existing implementation for the @Attribute property wrapper
#282
Open
thafner0 opened this issue
May 26, 2024
· 0 comments
At present to instantiate a property that is wrapped with the @Attribute property wrapper whose wrapped value conforms to one of the many ExpressibleBy(value type)Literal such as ExpressibleByStringLiteral:
This is because the @Element property wrapper doesn't conform to the ExpressibleByStringLiteral, unlike the @Attribute property wrapper. My suggestion is to the conditional conformance to the ExpressibleByStringLiteral protocol whenever the Value type parameter also conforms to the ExpressibleByStringLiteral protocol. (This suggestion also applies for the other protocols that are of the format ExpressibleBy(value type)Literal protocols such as ExpressibleByIntegerLiteral and ExpressibleByBooleanLiteral). The way that this would be done would be virtually identical to the way this is implemented in the @Attribute property wrapper. (As such, one could argue that this should be implemented with the definition of a protocol that satisfies its own requirements. This protocol could then be inherited by the @Attribute and @Element property wrappers in order to avoid repetitive code).
Regardless of the exact implementation, the adoption of this suggestion would permit the instantiation of the example type as follows (note the similarities between the two properties, despite their differing implementation on the XML side):
The text was updated successfully, but these errors were encountered:
thafner0
changed the title
Add conditional conformance to the Element property wrapper to the ExpressibleBy___Literal Swift Standard Library protocols similar to the existing implementation for the Attribute property wrapper
Add conditional conformance to the Element property wrapper to the ExpressibleBy___Literal Swift Standard Library protocols similar to the existing implementation for the Attribute property wrapper
May 26, 2024
thafner0
changed the title
Add conditional conformance to the Element property wrapper to the ExpressibleBy___Literal Swift Standard Library protocols similar to the existing implementation for the Attribute property wrapper
Add conditional conformance to the @Element property wrapper to the ExpressibleBy___Literal Swift Standard Library protocols similar to the existing implementation for the @Attribute property wrapper
May 26, 2024
At present to instantiate a property that is wrapped with the
@Attribute
property wrapper whose wrapped value conforms to one of the manyExpressibleBy
(value type)Literal
such asExpressibleByStringLiteral
:Currently in order to instantiate this type, one must do the following:
This is because the
@Element
property wrapper doesn't conform to theExpressibleByStringLiteral
, unlike the@Attribute
property wrapper. My suggestion is to the conditional conformance to theExpressibleByStringLiteral
protocol whenever theValue
type parameter also conforms to theExpressibleByStringLiteral
protocol. (This suggestion also applies for the other protocols that are of the formatExpressibleBy
(value type)Literal
protocols such asExpressibleByIntegerLiteral
andExpressibleByBooleanLiteral
). The way that this would be done would be virtually identical to the way this is implemented in the@Attribute
property wrapper. (As such, one could argue that this should be implemented with the definition of a protocol that satisfies its own requirements. This protocol could then be inherited by the@Attribute
and@Element
property wrappers in order to avoid repetitive code).Regardless of the exact implementation, the adoption of this suggestion would permit the instantiation of the example type as follows (note the similarities between the two properties, despite their differing implementation on the XML side):
The text was updated successfully, but these errors were encountered: