On Monday, 27 November 2023 at 09:53:48 UTC, Antonio wrote:
...but why?
All classes (and interfaces I think), at root of inheritance have
`Object` class, this class defines couple of generic methods, you
can find this class in object.d btw. One of those methods is
`bool opEquals(const
On Saturday, 25 November 2023 at 01:15:34 UTC, Alexandru Ermicioi
wrote:
On Friday, 24 November 2023 at 17:39:10 UTC, Antonio wrote:
...
Dunno if this might help, but I noticed that `==` sometimes
calls `opEquals(const Object) const` instead of overload
defined on class/interface, you might
On Friday, 24 November 2023 at 17:39:10 UTC, Antonio wrote:
...
Dunno if this might help, but I noticed that `==` sometimes calls
`opEquals(const Object) const` instead of overload defined on
class/interface, you might try and override it as well, and
delegate to your overload that deals
On Thursday, 23 November 2023 at 21:52:56 UTC, Jonathan M Davis
wrote:
I'd have to take the time to study your code in detail to see
whether what exactly you're seeing makes sense or not ...
My apologies... I should have proposed a more specific example.
```d
interface IOpt { bool
On Thursday, November 23, 2023 2:20:25 PM MST Antonio via Digitalmars-d-learn
wrote:
> * Why, when applied to interface, ```opEquals``` called directly
> behavior is not the same that when calling ```==``` ?
>
> * Is it the expected behaviour?
I'd have to take the time to stu
quot;extrange effects" I test an alternative equality that
fails too:
```d
assert( (cast (IOpt!int) new None!int) == (cast (IOpt!int) new
None!int));
```
What seems strange to me is that
```none!int.opEquals(none!int)``` works properly.
**Questions**
* Why, when applied to in
