A small step for mankind a giant leap for software.
The issue is the the SPF grammar (the rules for a valid .ifc file) is very elegant but minimal. You have (from the 2016) version for untyped_parameter (the attribute value we’re talking about here):
UNTYPED_PARAMETER = "$" | INTEGER | REAL | STRING | RHS_OCCURENCE_NAME
| ENUMERATION | BINARY | LIST .
So nothing like an equation. So the spf grammar you can wrap it as a string (but than you loose any information on the schema, all datatypes are strings then, no more positive constraints, so you loose a lot of expressiveness in the schema).
So isn’t there something for that? Of course there is an ISO standard for everything. In this case for example 10303-50 Mathematical Constructs if I’m not mistaken, but there isn’t any connection between IFC and this ISO standard. And on a schema level it would mean that every number needs to be encoded as a select of (REAL, function_expression). In short, STEP is just not equipped to embed constraints on such a deep syntactic level.
I think for that reason the examples from @jonm makes sense: encoding the constraints (IfcMetric) in additional definitions outside of the normal attribute values. There are issues that come from that as well, it’s not straightforward to just refer to an arbitrary attribute value (there isn’t a select of everything in the schema; there isn’t a foolproof way to refer to elements in sets either).
In that sense I think your syntax makes quite a bit of sense actually. But you’ll have to find another way to encode it (as a string probably or some other meta-schema / structure) and store it somewhere else (property set, IfcMetric / separate file / linked data) and also supply a true numeric value for the extrusion depth as it is not optional.