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
.unwrap_or_else(||
String::from("ab").try_into().expect("this check should have failed at generation time; please file a bug report under https://github.com/awslabs/smithy-rs/issues"))
when falling back to values modeled with @default for a structure member shape.
We use .unwrap_or() for primitives and .unwrap_or_else() for heap-allocated values, to only pay the cost of the heap allocation in a (lazily) invoked closure when the value is actually not set in the builder.
However, this code is problematic because:
We perform the try_into() check for a static value every time we build the builder, which is costly.
We panic in the (unlikely) case that the Smithy library did not correctly check that the modeled @default value is valid according to the modeled constraints.
In a similar spirit to #2026, we can do away with these problems by checking early at service startup that the modeled default values are indeed valid according to the modeled constraints, panicking otherwise, and we can store the result in a OnceCell that can be reused for a slight performance gain.
The text was updated successfully, but these errors were encountered:
In #1879, we started generating code of the form:
when falling back to values modeled with
@default
for a structure member shape.We use
.unwrap_or()
for primitives and.unwrap_or_else()
for heap-allocated values, to only pay the cost of the heap allocation in a (lazily) invoked closure when the value is actually not set in the builder.However, this code is problematic because:
try_into()
check for a static value every time we build the builder, which is costly.@default
value is valid according to the modeled constraints.In a similar spirit to #2026, we can do away with these problems by checking early at service startup that the modeled default values are indeed valid according to the modeled constraints, panicking otherwise, and we can store the result in a
OnceCell
that can be reused for a slight performance gain.The text was updated successfully, but these errors were encountered: