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 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! Regards, Halil
