On Wednesday, 26 June 2013 at 04:59:19 UTC, cal wrote:
> On Wednesday, 26 June 2013 at 04:06:05 UTC, Jonathan M Davis wrote:
>> Yeah, that should work for the conditions in if, while, and for loops but
>> won't work for anything else (_maybe_ ternary operators, but I'm not sure).
>> So, if you need to be able to do !obj in the general case, that's not going to
>> work
> ...
>
> import std.stdio;
>
> struct S {
>   int x;
>   bool opCast(T)() if (is(T == bool)) {
>     return x == 0;
>   }
> }
>
> void main() {	
>   auto s = S(1);
>   auto b = !s;
>   writeln(b);	// true
> }
>
> Is this not supposed to work?

I should have also added that the overloaded ! method returns a class instance and not a bool.

-Eric

On Wednesday, June 26, 2013 07:14:36 cal wrote:
> But that code I posted does work, and gives the output shown. Am I misunderstanding?

Then my understanding of how ! is handled is wrong. Apparently !s does get replaced with !cast(bool)s, or it couldn't work. But note that

bool b = s;

doesn't work, so as I said, it's not the case that opCast gives you an implicit cast. It's just the cases where cases where the compiler inserts an explicit cast for you that it looks like it gives you an implicit cast. But apparently, there was a case that it inserts an explicit cast of which I was not aware.

- Jonathan M Davis

On Wednesday, June 26, 2013 07:15:19 Eric wrote:
> I should have also added that the overloaded ! method returns a class instance and not a bool.

Well, at that point, you're completely out of luck with regards to overloading !. In general, D doesn't really support overloading operators in a manner that doesn't match how the built-in types work. It does things like assume that <, <=, >=, and > will act the same way that they do with the built-in types and uses opCmp to extrapolate all of those operators. In some cases, you _can_ make overloaded operators return types that make it so that they don't function anything like the built-in types (e.g. opBinary with + could return a completely unrelated type that had nothing to do with the original type or with addition), but in pretty much any case where the compiler can get away with using the same overloaded operator for multiple operators, it does it. So, a number of decisions were made to better support correctness with types that actually try and overload operators to match what the built-in types do without caring about how that would affect types that would try and overload them to do unrelated stuff.

- Jonathan M Davis

On Wednesday, 26 June 2013 at 05:29:49 UTC, Jonathan M Davis wrote:
> On Wednesday, June 26, 2013 07:15:19 Eric wrote:
>> I should have also added that the overloaded ! method returns a
>> class instance and not a bool.
>
> Well, at that point, you're completely out of luck with regards to overloading
> !. In general, D doesn't really support overloading operators in a manner that
> doesn't match how the built-in types work. It does things like assume that <,
> <=, >=, and > will act the same way that they do with the built-in types and
> uses opCmp to extrapolate all of those operators. In some cases, you _can_
> make overloaded operators return types that make it so that they don't
> function anything like the built-in types (e.g. opBinary with + could return a
> completely unrelated type that had nothing to do with the original type or
> with addition), but in pretty much any case where the compiler can get away
> with using the same overloaded operator for multiple operators, it does it.
> So, a number of decisions were made to better support correctness with types
> that actually try and overload operators to match what the built-in types do
> without caring about how that would affect types that would try and overload
> them to do unrelated stuff.
>
> - Jonathan M Davis

Yeah, basically, you define:
* opCast(bool) //to test both "true" and "false"
* opEqual //test equality (both == and !=)
* opCmp //Comparison (< > <= >=)

And everything gets defined from these. It also works that way for operators:
op++ is defined in terms or ++op.
And if you define "op+", then defining op++ becomes entirely optional!

This is a cool feature, although there are those *very* rare cases where it gets in your way.

For example, the other day, I was trying to implement a "tribool":
http://www.boost.org/doc/libs/1_53_0/doc/html/tribool/tutorial.html

It did not work, I mean: AT ALL!

This is because for a tribool, being "not true" does not imply being "false"...