Stream: git-cranelift

Topic: cranelift / Issue #976 Make Settings more static


view this post on Zulip 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:

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.

view this post on Zulip 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:

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.

view this post on Zulip GitHub (Jan 14 2020 at 08:56):

bnjbvr commented on Issue #976:

Oops, wrong commit number; it was supposed to close #1164.

view this post on Zulip 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:

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: Dec 23 2024 at 13:07 UTC