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
Once we will support associated types we might consider removing additional support for ExecC and QueryC associated types and allow users to specify their own types as custom using the sv::custom() attribute.
Motivation
Currently our API allows interface to be defined in two ways:
through associated type
through sv::custom attribute
Since we already forward the associated types I think it would make sense to simplify the API by allowing the user to use only the sv::custom attribute with either solid type or the associated type.
I see the benefit of using standardized type names for better clarity when implementing the interface which type is responsible for what, but I think that it would be easier for user to look in a single place to determine the custom types.
This also has a benefit of simplifying sylvia code.
Once we will support associated types we might consider removing additional support for
ExecC
andQueryC
associated types and allow users to specify their own types as custom using thesv::custom()
attribute.Motivation
Currently our API allows interface to be defined in two ways:
sv::custom
attributeSince we already forward the associated types I think it would make sense to simplify the API by allowing the user to use only the
sv::custom
attribute with either solid type or the associated type.I see the benefit of using standardized type names for better clarity when implementing the interface which type is responsible for what, but I think that it would be easier for user to look in a single place to determine the custom types.
This also has a benefit of simplifying
sylvia
code.The text was updated successfully, but these errors were encountered: