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
One kind of type that isn't representable in the marker model is a UUID that's "either this or that".
For example, you could imagine something like this, which I'll call the "concrete model":
structTypedUuid<T>{uuid:Uuid,type_info:T,}enumFooOrBar{Foo,Bar,}implTypedUuidKindforFooOrBar{fntag(&self) -> TypedUuidTag{// match on self.type_info}}
While the concrete model is more flexible, it also carries some rather large downsides. The main one is that it complicates our APIs. For example, for an ergonomic API we'd need
Similarly, the concrete model would also complicate the FromStr impl, for which we have two options:
Restrict it to T: Default.
Require that the input string specify a tag, which is a pretty large behavior change that can break lots of things if not done with care.
The GenericUuid trait becomes more complex as well -- part of the benefit of the marker model is easily being able to write code that's generic over typed and untyped UUIDs. It's not clear how well that would survive in the concrete model.
Furthermore, the same result can be achieved in other ways most of the time -- users can just as well write their own enums "outside" the type param:
And that would in many ways provide more clarity than putting the param inside the UUID. This approach would also let more data be associated with each variant, which is often required in practice.
Based on all this I'd like to keep the current marker model for now, and see how things evolve in the future.
The text was updated successfully, but these errors were encountered:
sunshowers
changed the title
Why marker types and not a concrete value?
Why marker types and not concrete values?
Feb 1, 2024
Our current model is what I'd refer to as the "marker model":
One kind of type that isn't representable in the marker model is a UUID that's "either this or that".
For example, you could imagine something like this, which I'll call the "concrete model":
While the concrete model is more flexible, it also carries some rather large downsides. The main one is that it complicates our APIs. For example, for an ergonomic API we'd need
Similarly, the concrete model would also complicate the
FromStr
impl, for which we have two options:T: Default
.The
GenericUuid
trait becomes more complex as well -- part of the benefit of the marker model is easily being able to write code that's generic over typed and untyped UUIDs. It's not clear how well that would survive in the concrete model.Furthermore, the same result can be achieved in other ways most of the time -- users can just as well write their own enums "outside" the type param:
And that would in many ways provide more clarity than putting the param inside the UUID. This approach would also let more data be associated with each variant, which is often required in practice.
Based on all this I'd like to keep the current marker model for now, and see how things evolve in the future.
The text was updated successfully, but these errors were encountered: