| |
|
cc ![cc's Gravatar profile Gravatar of cc](//www.gravatar.com/avatar/ef871764bb96514086e6e6289ac3f5f3?d=identicon&s=80)
Posted in reply to Nick Treleaven
| 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().
|