GitHub (Jan 13 2020 at 21:42): GitHub (Jan 13 2020 at 21:42):sstangl closed Issue #976:
Right now, methods on the settings builder are all taking strings as inputs, and maybe strings as values. This makes it very dynamic, and allows a range of runtime errors like a setting doesn't exist, or the provided value doesn't have the right type.
Instead, we could generate methods on the settings builder for each setting:
- for bool values, they would take a bool parameter.
- for enum values, they would take a (Rust) enum parameter.
Then, the entire range of errors described by the enum SetError would disappear, and all these errors would become compile-time errors, which I think is safer and less error-prone.
This implies generating more code for these settings. We don't have thousands of them, so it shouldn't be a problem. It would be a breaking API change, too.
GitHub (Jan 14 2020 at 08:56):bnjbvr reopened Issue #976:
Right now, methods on the settings builder are all taking strings as inputs, and maybe strings as values. This makes it very dynamic, and allows a range of runtime errors like a setting doesn't exist, or the provided value doesn't have the right type.
Instead, we could generate methods on the settings builder for each setting:
- for bool values, they would take a bool parameter.
- for enum values, they would take a (Rust) enum parameter.
Then, the entire range of errors described by the enum SetError would disappear, and all these errors would become compile-time errors, which I think is safer and less error-prone.
This implies generating more code for these settings. We don't have thousands of them, so it shouldn't be a problem. It would be a breaking API change, too.
GitHub (Jan 14 2020 at 08:56):bnjbvr commented on Issue #976:
Oops, wrong commit number; it was supposed to close #1164.
GitHub (Feb 28 2020 at 23:26):alexcrichton transferred Issue #976:
Right now, methods on the settings builder are all taking strings as inputs, and maybe strings as values. This makes it very dynamic, and allows a range of runtime errors like a setting doesn't exist, or the provided value doesn't have the right type.
Instead, we could generate methods on the settings builder for each setting:
- for bool values, they would take a bool parameter.
- for enum values, they would take a (Rust) enum parameter.
Then, the entire range of errors described by the enum SetError would disappear, and all these errors would become compile-time errors, which I think is safer and less error-prone.
This implies generating more code for these settings. We don't have thousands of them, so it shouldn't be a problem. It would be a breaking API change, too.
Last updated: Nov 22 2024 at 17:03 UTC