Denis Koroskin wrote: > On Mon, 07 Dec 2009 10:36:16 +0300, Johan Granberg > <[email protected]> wrote: > >> Andrei Alexandrescu wrote: >> >>> Brad Roberts wrote: >>>> Andrei Alexandrescu wrote: >>>>> bearophile wrote: >>>>>> Walter Bright: >>>>>> >>>>>>> Think of it like the "bool" operator overload. bool gives a direct >>>>>>> way for user defined times to be tested for if statements, etc. >>>>>>> Similarly, U+ gives a direct way for user defined types to be >>>>>>> converted to their most desired arithmetic type. >>>>>> I'd like opBool in D, for example to implement multiprecision numbers >>>>>> that can be used as integers in: if (somenumber) {... >>>>> Unfortunately experience with C++ has shown that things look simpler >>>>> than they are. If opBool is an implicit conversion to bool, then all >>>>> sorts of weird expressions are allowed. That's why conversion to bool >>>>> is >>>>> flat out unrecommended in C++. Instead, various libraries found >>>>> alternate ways to allow testing with if without compromising things >>>>> too >>>>> much. Loki uses conversion to an opaque pointer type. Boost uses >>>>> conversion to a pointer to member. The standard itself uses, I think, >>>>> conversion of iostreams to void*. >>>> >>>> Isn't one of the key problems that bool conversion introduces is the >>>> follow on >>>> conversion to integral types? If implicit bool -> integral conversion >>>> wasn't allowed, T -> bool conversion would be less problematic, no? >>> >>> That is correct, and "less problematic" is exactly how I'd put it. >>> There's a problem left. Assuming bool -> numeric conversion is >>> impossible, there's still a problem. First, consider a class, array, >>> pointer, or number x. This compiles: >>> >>> if (x) stmt >>> >>> This also compiles: >>> >>> x ? expr1 : expr2 >>> >>> But this doesn't compile: >>> >>> bool b = x; >>> >>> Now consider we design tests to use opBool that effects implicit >>> conversion to bool. Then, for a user-defined type x, all of the three >>> samples above compile. Which means we have introduced a gratuitous >>> incompatibility between user-defined and built-in types. >>> >>> Then consider another problem: a type that allows if (x) also wants to >>> allow if (!x). It's the natural thing to want. Then we need to define >>> opBool and opUnary!"!" to work in concert, redundantly. Bleh. >>> >>> I'm not sure how big problems these are. I think they are threatening >>> enough that style manuals and coding standards mention both. >>> >>> Using double negation !!x throughout, there are only advantages and no >>> disadvantage. I hit that design with Pacquiao punches over the past week >>> or so, and couldn't find any shortcoming. It's consistent across >>> positive and negated uses, easy to understand, easy to define, >>> consistent with built-in types, and Walter likes it. >>> >>> >>> Andrei >> >> Couldn't we solv that by instead of introducing opBool, introduce opTrue. >> Which is defined as yielding a type testable for truth and is only >> invoked >> in the same situations that class references are used as thruth values? >> To >> me this looks like a simple solution. > > OpTrue also implies opFalse, which is redundant.
It was the semantics I was after I just choose a different name to keep the concepts appart.
