Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert @default values of constrained types only once #2134

Open
david-perez opened this issue Dec 22, 2022 · 0 comments
Open

Convert @default values of constrained types only once #2134

david-perez opened this issue Dec 22, 2022 · 0 comments
Labels
server Rust server SDK

Comments

@david-perez
Copy link
Contributor

In #1879, we started generating code of the form:

.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:

  1. We perform the try_into() check for a static value every time we build the builder, which is costly.
  2. 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.

@david-perez david-perez added the server Rust server SDK label Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
server Rust server SDK
Projects
None yet
Development

No branches or pull requests

1 participant