On Wednesday, 8 May 2024 at 10:24:07 UTC, Nick Treleaven wrote:
On Wednesday, 8 May 2024 at 04:27:13 UTC, cc wrote:
It doesn't allow a simple boolean to be used as an argument,
or any other Flag as they are different instantiations of a
template rather than equivalent aliases.
It is however awful, cumbersome, annoying design and needs to
be completely phased out now that we have named arguments.
Flag enforces that the argument says what it relates to. `true`
does not say what it relates to. Named arguments are optional,
so I don't see how they could make Flag redundant.
It's pointless mandatory verbosity. StopWatch ctor only takes
one boolean argument. It doesn't *need* to specify what it
relates to. You either already know, or you have to look it up
anyway. Flags made sense when you might get the order of
multiple bools confused, but if there's only one, *or* if you can
use named arguments to avoid ambiguity, there's no point in
demanding every parameter be a unique type. It's easy to
remember I can pass a bool to a StopWatch to autostart it. It's
less easy to remember that a specific unique type needs to be
used, and remembering whether the name/casing of that type was
Start, StartNow, StartAuto, Autostart, AutoStart, autostart,
autoStart, etc. We have a tool in our box already called `true`
and that solves the problem. If we had to type out the full name
of every argument passed to every function ever written we may as
well just adopt ObjC Cocoa style and call it
StopWatchWithAutoStartBool().
