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
However, this pattern cannot be represented in any way in Rune as far as I can tell, since Any types can't be ConstValue -- and that's the only pattern for associated values I can find. For ergonomics, it'd be nice if one could still do it, even if (technically) the type isn't POD from rune's perspective. For example, an associated_field_function? Not sure what would be the most efficient from the implementation perspective. Another option would be to have some form of ConstValue::UserDefined(Bytes, ToValueFn), though I'm not sure about how that'd work in actual const-eval.
The text was updated successfully, but these errors were encountered:
I thinkAny types can be constant values - if they can be represented with ConstValue.
What would be needed for external types are two things:
The data being stored. Probably a constant Tuple or constant Object, and;
The metadata which identifiers the type, probably its type hash.
These could be represented using six new variants:
ConstValue::EmptyStruct.
ConstValue::TupleStruct.
ConstValue::Struct.
ConstValue::EmptyVariant.
ConstValue::TupleVariant.
ConstValue::StructVariant.
The metadata of structs would need the type hash of the struct they represent, variants would need two pieces of metadata, the type hash of the enum it belongs to and the type hash of the variant.
The metadata can then be used by a Vm to convert a ConstValue into a Value as needed by looking up the relevant RTTI. Trying to coerce a ConstValue from something incompatible would result in an error, similar to how trying to construct a structure in the Vm would be an error if it doesn't have the appropriate fields.
A common pattern in Rust is something like this:
However, this pattern cannot be represented in any way in Rune as far as I can tell, since
Any
types can't be ConstValue -- and that's the only pattern for associated values I can find. For ergonomics, it'd be nice if one could still do it, even if (technically) the type isn't POD from rune's perspective. For example, anassociated_field_function
? Not sure what would be the most efficient from the implementation perspective. Another option would be to have some form ofConstValue::UserDefined(Bytes, ToValueFn)
, though I'm not sure about how that'd work in actual const-eval.The text was updated successfully, but these errors were encountered: