Halil Pasic <[email protected]> writes: > On Thu, 15 Jan 2026 08:28:51 +0100 > Markus Armbruster <[email protected]> wrote: > >> I understand that you're mirroring how @poll-grow and @poll-shrink work, >> but let's ignore that for a minute. >> >> Compare four possible interfaces: >> >> 1. Optional @poll-weight defaults to 2. Values <= 0 are rejected. >> >> 2. Optional @poll-weight defaults to 2. Value 0 is replaced by the >> default value 2. Values < 0 are rejected. >> >> 3. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value >> 0 makes the system pick a value, namely 2. >> >> 4. Optional @poll-weight defaults to 0. Values < 0 are rejected. Value >> 0 makes the system pick a value. It currently picks 2. >> >> The difference between 3. and 4. is that 3. makes "system picks 2" part >> of the contract, while 4. doesn't. >> >> 1. is the simplest. Is 2.'s additional complexity worthwhile? 3.'s? >> 4.'s? > > Isn't there more options? Like
Yes :) > 5. Optional @poll-weight defaults to system-default. Value 0 is replaced > by the system pick the system default value. Currently the system default > value is 2. Values < 0 are rejected. > > That would mean: > * current value inspectable > * system default not part of the interface contract > * interface offers a "please go back to value not user specified: > operation > > BTW I like your approach with explicitly listing and evaluating the > options a lot! Thanks!
