pub enum Const {
Bool(bool),
Int(i64),
Float(f64),
Str(&'static str),
List(&'static [Const]),
Map(&'static [(&'static str, Const)]),
}Expand description
A declared default, in the form a generated registry can hold as a const.
The same shapes as Value, with borrowed strings and slices so nothing is allocated
until somebody actually asks for the default of a setting no layer supplied.
Variants§
Bool(bool)
Int(i64)
Float(f64)
Str(&'static str)
List(&'static [Const])
Map(&'static [(&'static str, Const)])
Key-value pairs, ordered by the generator so the Value it becomes is too.
Implementations§
Source§impl Const
impl Const
Sourcepub fn matches(self, value: &Value) -> bool
pub fn matches(self, value: &Value) -> bool
Whether value is this constant, or is written the same way.
The same shape compares directly, without building the Value this stands for: the strict
case is the common one, it runs once per declared choice for every value supplied, and a
setting with choices is usually a string — where the comparison would otherwise allocate a
copy of the choice to throw away.
The shapes differing is not a mismatch, though, and this is the part worth explaining. A spec
writes choice 4 under type="string" as readily as choice "4", and by the time a value
reaches here it has been coerced to the declared type — so the choice is an integer and the
value is the string 4, and a strict comparison refuses a value the spec plainly allows.
Comparing what they are written as is the same question the coercion already answered:
Ty::String turns 4 into "4", and Ty::Float turns 1 into 1.0, whose text is 1
either way. Only scalars get here — PropMeta::refuses walks a
list or a table item by item first — so there is no way for a,b the string to be mistaken
for [a, b] the list.