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
pt { bool opEquals(IOpt other) const @safe pure; }
class None : IOpt { bool opEquals(IOpt other) const @safe pure =>
true; }
void main() {
None
a = new None(),
b = new None();
IOpt
a2 = a,
b2 = b;
assert(a == b);
assert(a2 == a);
assert(b2 == b);
assert(a2 ==
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 s
```d
interface IOpt(T)
{
T value();
bool empty();
bool opEquals(IOpt!T other);
}
class None(T) : IOpt!T
{
bool empty() => true;
T value(){ throw new Exception("None has not a value"); }
bool opEquals(IOpt!T other)=>other.empty;
}
class Some(T) : IOpt!T
{
this(
On Tuesday, 18 May 2021 at 10:14:26 UTC, PinDPlugga wrote:
But what I do not understand is why opEquals is necessary and
where in the implementation of toHash it plays its role? Since
area1 and area2 have different static arrays of Points I
understand why `typeid(points).getHash(&po
sh(&points);
}
```
I looked into the object library documentation and saw that the
template getHash calls hashOf which calls
core.internal.hash.hashOf etc.
But what I do not understand is why opEquals is necessary and
where in the implementation of toHash it plays its role? Since
area1
On 3/3/21 1:37 PM, Jack wrote:
the one that the compiler defaults to when you don't provide one?
There's no default opCmp.
For opEquals, it's a memberwise comparison.
-Steve
the one that the compiler defaults to when you don't provide one?
x27;t the opEquals get
modified appropriately even though the struct is extern(C++)?
Can I tell D to only compare the non-padding parts? Or is
there a msvc/clang compiler switch to tell them to initialize
padding to 0?
https://dlang.org/changelog/2.085.0.html#no-cmpsb
Thanks! Great to see
On Wednesday, 21 October 2020 at 19:23:43 UTC, Simon van Bernem
wrote:
The only explanation I can think of is that D memcmps the
entire struct including the padding. Is this correct?
If so, what can I do about this? Why doesn't the opEquals get
modified appropriately even though the stru
I ask this question because I chased a very very nasty bug all
the way down, and I think I found the offender:
I have a extern(C++) struct that contains an 8-byte integer
followed by a 4-byte enum value. I came across two variables of
that type, that are not equal by comparison (no opEquals
On Monday, 28 September 2020 at 08:26:15 UTC, Per Nordlöw wrote:
In the case where the AA-KeyType is a class (which is
represented as a pointer in D) I want the equality (opEquals)
and the hashing (toHash) of the AA to compare and hash the
pointers themselves, not the fields the classes points
-KeyType is a class (which is represented
as a pointer in D) I want the equality (opEquals) and the hashing
(toHash) of the AA to compare and hash the pointers themselves,
not the fields the classes points to.
On Sunday, 27 September 2020 at 19:37:10 UTC, Per Nordlöw wrote:
On Sunday, 27 September 2020 at 18:39:10 UTC, Per Nordlöw wrote:
How do I defined an AA with class as key where keys are
compared using `is` instead of `opEquals`? Do I have to store
the key as a `void*`?
I got a good answer at
On Sunday, 27 September 2020 at 18:39:10 UTC, Per Nordlöw wrote:
How do I defined an AA with class as key where keys are
compared using `is` instead of `opEquals`? Do I have to store
the key as a `void*`?
I got a good answer at
https://dlang.slack.com/archives/C1ZDHBB2S/p1601234030016700
On Sunday, 27 September 2020 at 18:56:15 UTC, Ferhat Kurtulmuş
wrote:
By looking at object.d and aaA.d of druntime, I d say you don't
need to use void*. Object class has required infrastructure
ready for using classes aa keys (have not tried though). Object
class has both toHash and opE
On Sunday, 27 September 2020 at 18:39:10 UTC, Per Nordlöw wrote:
How do I defined an AA with class as key where keys are
compared using `is` instead of `opEquals`? Do I have to store
the key as a `void*`?
By looking at object.d and aaA.d of druntime, I d say you don't
need to use
How do I defined an AA with class as key where keys are compared
using `is` instead of `opEquals`? Do I have to store the key as a
`void*`?
On Friday, 28 August 2020 at 13:35:43 UTC, Alexandru Ermicioi
wrote:
On Friday, 28 August 2020 at 12:29:20 UTC, Simen Kjærås wrote:
Seems that these methods should be rooted out from Object, and
placed in respective interfaces like:
-
interface Equatable(T) {
bool opEquals(T
On Friday, 28 August 2020 at 12:29:20 UTC, Simen Kjærås wrote:
Seems that these methods should be rooted out from Object, and
placed in respective interfaces like:
-
interface Equatable(T) {
bool opEquals(T value);
}
-
Then it would be a lot more simple. People who want
Yup. There's a reason I'm saying it's suboptimal. FWIW, you can
limit the taint by using @trusted lambdas.
One of the reasons this hasn't been fixed is idiomatic D code
very rarely uses classes, but that does not mean they're always
the wrong tool.
Could we just t
On Friday, 28 August 2020 at 10:42:09 UTC, Alexandru Ermicioi
wrote:
...
Also, why it is limited to just objects? It seems that this
function enforces symmetry between two objects. What about rest
of the possible types, such as structs, unions?
ifice safety for rest of
types, such as structs, unions & enums for the sake of objects
being able to compare.
Could we just template that opEquals in this manner:
---
bool opEquals(T : Object, X : Object)(T lhs, X rhs)
{
if (lhs is rhs) return true;
if (lhs is null || rhs is nul
On Friday, 28 August 2020 at 08:16:01 UTC, Alexandru Ermicioi
wrote:
Hi everyone,
there is https://issues.dlang.org/show_bug.cgi?id=21180 bug,
anyone knows how to avoid it?
Test case:
-
import std;
class Silly {
bool opEquals(const Silly silly) const @safe {
return
On Friday, 28 August 2020 at 08:16:01 UTC, Alexandru Ermicioi
wrote:
Hi everyone,
Would be glad at least to pointers, where in dmd is logic for
operator overloading happens, as well as for overloading rules,
so I could fix it myself, if no-one is able to pick up it.
Hi everyone,
there is https://issues.dlang.org/show_bug.cgi?id=21180 bug,
anyone knows how to avoid it?
Test case:
-
import std;
class Silly {
bool opEquals(const Silly silly) const @safe {
return silly is this;
}
alias opEquals = Object.opEquals;
}
bool
> this.x = x;
>}
>
>override bool opEquals(Object o) const @trusted
>{
> if (ExampleC rhs = cast(ExampleC)o) {
>return this.x == rhs.x;
> }
> return false;
>}
> }
>
> @safe unittest
> {
> auto c = new Example
On Sunday, 24 May 2020 at 08:57:28 UTC, Luis wrote:
dmd ignores @trusted or @safe on opEquals, throwing this error :
onlineapp.d(27): Error: @safe function
onlineapp.__unittest_L24_C7 cannot call @system function
object.opEquals
An override @system or @trusted function can't be @safe,
Lets take this example code (https://run.dlang.io/is/Vkpx9j) :
´´´D
import std;
void main()
{
}
class ExampleC
{
int x;
this (int x) @safe
{
this.x = x;
}
override bool opEquals(Object o) const @trusted
{
if (ExampleC rhs = cast(ExampleC)o) {
return this.x == rhs.x
S.
I have written opEquals to compare an S to a uint.
How do I write code to compare a uint to an S?
I didn't know that it works both ways already:
import std.stdio;
struct S {
bool opEquals(uint u) {
writeln("called");
return true;
}
}
void main() {
S s;
s
I am creating a specialized bit pattern (secretly represented as
a uint) as a struct S, but want to avoid `alias this` to maintain
encapsulation excepting where I overtly say. Specifically, I want
to avoid making arithmetic and inequalities available for S.
I have written opEquals to compare
On Wednesday, 19 June 2019 at 17:15:31 UTC, Ali Çehreli wrote:
On 06/19/2019 08:28 AM, harfel wrote:
You need to define toHash() member function as well:
https://dlang.org/spec/hash-map.html#using_struct_as_key
Ali
Thanks Ali,
This fixed my problem, of course. Amazing that such a beginner
On 06/19/2019 08:28 AM, harfel wrote:
Everything works nicely if I compare the structs directly. Yet when they
are used as keys in an associative array, the code throws an exception
that I do not understand.
You need to define toHash() member function as well:
https://dlang.org/spec/hash-m
I am trying to overload opEquals for a struct. The struct will
hold class objects that define their own opEquals so the default
bitwise comparison is not good for me.
Everything works nicely if I compare the structs directly. Yet
when they are used as keys in an associative array, the code
On Wednesday, 23 January 2019 at 17:28:37 UTC, H. S. Teoh wrote:
The best way to do this is to use a string DSL or a delegate as
template argument. For example:
auto result = User.filter!q{ User.name == "John" };
or:
auto result = User.filter!(u => u.name == "John");
I didn
On Thursday, 24 January 2019 at 00:47:37 UTC, Ali Çehreli wrote:
Yeah, that can't work. Remove the bool-returning one and your
code works with the 'alias this' above.
Wow, this is an amazing workaround! I didn't think about it in
that way.
It perfectly solves the issue.
Thank you!
On Wed, 23 Jan 2019 15:19:06 +, Jacob Shtokolov wrote:
> I'm wondering, is that possible to declare multiple versions of
> opEquals() and evaluate them in the different places depending on return
> type?
I looked at this a while ago for similar reasons. It didn't pan out.
;
Op op;
bool value() const {
final switch (op) with (Op) {
case Equals:
return left == right;
case NotEquals:
return left != right;
}
}
alias value this;
}
> So I'm making the two versions of opEquals: one returns a
> BinaryExpression, and
On Wed, Jan 23, 2019 at 03:19:06PM +, Jacob Shtokolov via
Digitalmars-d-learn wrote:
> Hi,
>
> I'm trying to check whether it's possible to implement Python's
> SQLAlchemy-like query syntax in D, but I get stuck a bit.
>
> Here is a simple example of what I want to achieve:
>
> ```
> auto r
On Wednesday, 23 January 2019 at 15:28:02 UTC, Jonathan M Davis
wrote:
But regardless of the specifics of operator overloading in D, D
does not support overloading _any_ functions on the return type.
Thanks!
of a bool (let's call it `struct
> BinaryExpression`).
>
> So I'm making the two versions of opEquals: one returns a
> BinaryExpression, and the second - a boolean value.
>
> However, when I want to use the same expression for the `if`
> operator, the compiler cannot
t;);
result = User.filter(User.age > 18);
```
Expressions like `User.id == 10`, `User.age > 18`, etc. should
return a struct instead of a bool (let's call it `struct
BinaryExpression`).
So I'm making the two versions of opEquals: one returns a
BinaryExpression, and the second - a
t`.
>
> This is a severe limitation. Are there any plans on fixing this
> or do I have to wait for Andrei's proposed ProtoObject?
ProtoObject _is_ the proposed fix, but if you want to use Object's opEquals
in @safe code, you can always create a wrapper function that'
On Tuesday, 25 December 2018 at 14:27:39 UTC, Per Nordlöw wrote:
This is a severe limitation. Are there any plans on fixing this
or do I have to wait for Andrei's proposed ProtoObject?
Ignore opEquals and use your own interface.
On Tuesday, 25 December 2018 at 00:32:55 UTC, Paul Backus wrote:
No, because equality comparison between classes lowers to
`object.opEquals` [1], which takes both parameters as `Object`.
This is a severe limitation. Are there any plans on fixing this
or do I have to wait for Andrei's proposed
`object.opEquals` [1], which takes both parameters as `Object`.
If you call car1.opEquals(car2) directly, it should work.
[1]
https://github.com/dlang/druntime/blob/master/src/object.d#L1051
ersion(unittest)
{
private static:
class Thing
{
@property override bool opEquals(const scope Object that)
const @safe pure nothrow @nogc
{
if (typeid(this) !is typeid(that)) { return false; }
assert(0);
}
@property final bool op
On Monday, 20 August 2018 at 19:36:15 UTC, werter wrote:
The code below doesn't work. Is it possible to make a pure
opEquals in a class?
[...]
pure bool opEquals(const A rhs) const
{
return b == rhs.b;
}
It do
The code below doesn't work. Is it possible to make a pure
opEquals in a class?
void main()
{
class A
{
bool a;
int b;
this(bool g, int h)
{
a = g;
I have a struct with a mixin(bitfields) containing many small
bitfields. I also have a class member in the struct.
And because I want the class member to compare by using `is` I
need to define
bool opEquals(const scope typeof(this) that) const @safe pure
nothrow @nogc
On 9/19/17 4:28 PM, Neia Neutuladh wrote:
Could be a bit simpler than that, depending on your needs:
bool opEquals(Object other) const nothrow @nogc
{
auto f = cast(typeof(this)) other;
if (f is null) return false;
return this.tupleof == other.tupleof;
}
That doesn't co
pending on your needs:
bool opEquals(Object other) const nothrow @nogc
{
auto f = cast(typeof(this)) other;
if (f is null) return false;
return this.tupleof == other.tupleof;
}
directly instead of having to find the member
name and using mixins?
-Steve
Hmm, I'm sure I had tried it before and failed, but now I've managed to
do so and it's really simpler (https://run.dlang.io/is/GJkokW):
```
auto opEquals()(auto ref const(typeof(this)) rhs)
{
On 9/19/17 8:01 AM, drug wrote:
I iterate over struct members and check against equality depending on
member type. is there more simple/cleaner/better way to achieve this
functionality? Especially without string mixins?
Why not just use tupleof directly instead of having to find the member
na
19.09.2017 15:01, drug пишет:
I iterate over struct members and check against equality depending on
member type. is there more simple/cleaner/better way to achieve this
functionality? Especially without string mixins?
oops, https://run.dlang.io/is/PbZE5i
I iterate over struct members and check against equality depending on
member type. is there more simple/cleaner/better way to achieve this
functionality? Especially without string mixins?
s a simple comparison between 2 objects. How to make
opEquals nothrow ?
You can't. Object.opEquals is not nothrow, so object.opEquals
is not nothrow (note the former is the virtual member
function, the latter is a global function which is what the
compiler actually calls).
It is a le
On Thursday, 20 July 2017 at 15:10:24 UTC, Aldo wrote:
extern(C) nothrow
{
void onMouseClick(GLFWwindow* window, int button, int
action, int d)
{
try
{
// my code
}
catch
{
}
}
}
Tangent but an easy way of nothrowing:
extern(C
between 2 objects. How to make opEquals
nothrow ?
You can't. Object.opEquals is not nothrow, so object.opEquals is not
nothrow (note the former is the virtual member function, the latter is
a global function which is what the compiler actually calls).
It is a legacy limitation. Until we
On Thursday, 20 July 2017 at 14:59:50 UTC, Steven Schveighoffer
wrote:
On 7/20/17 10:38 AM, Aldo wrote:
Hello,
im tring to add nothrow keyword in my code, but compilation
fails :
function 'object.opEquals' is not nothrow
its a simple comparison between 2 objects. How to make
On 7/20/17 10:38 AM, Aldo wrote:
Hello,
im tring to add nothrow keyword in my code, but compilation fails :
function 'object.opEquals' is not nothrow
its a simple comparison between 2 objects. How to make opEquals nothrow ?
You can't. Object.opEquals is not nothrow, so obj
On Thursday, 20 July 2017 at 14:38:03 UTC, Aldo wrote:
Hello,
im tring to add nothrow keyword in my code, but compilation
fails :
function 'object.opEquals' is not nothrow
its a simple comparison between 2 objects. How to make opEquals
nothrow ?
thanks
Could you show some code.
Hello,
im tring to add nothrow keyword in my code, but compilation fails
:
function 'object.opEquals' is not nothrow
its a simple comparison between 2 objects. How to make opEquals
nothrow ?
thanks
On Sunday, 31 July 2016 at 18:57:50 UTC, Jack Stouffer wrote:
On Sunday, 31 July 2016 at 17:48:48 UTC, BLM768 wrote:
writeln(n1.hashOf == n2.hashOf); // false = BAD!
Ok, yeah that is bad.
Next question: what's the fastest hashing implementation that
will provide the least collisions? Is ther
On Sunday, 31 July 2016 at 18:57:50 UTC, Jack Stouffer wrote:
Next question: what's the fastest hashing implementation that
will provide the least collisions? Is there a hash
implementation that's perfered for AAs?
I've heard that FNV-1a is a decent general-purpose option, and
it's fairly str
On Monday, 1 August 2016 at 10:35:29 UTC, pineapple wrote:
Every hashing function will produce collisions.
Not totally true: when the hash map content is static (i.e known
at compile time) there are probabilities that a perfect hashing
function exists. But these kind of functions are a bit sp
On Sunday, 31 July 2016 at 18:57:50 UTC, Jack Stouffer wrote:
Next question: what's the fastest hashing implementation that
will provide the least collisions? Is there a hash
implementation that's perfered for AAs?
There's no hashing function that would be specifically better for
associative
On Sunday, 31 July 2016 at 17:48:48 UTC, BLM768 wrote:
writeln(n1.hashOf == n2.hashOf); // false = BAD!
Ok, yeah that is bad.
Next question: what's the fastest hashing implementation that
will provide the least collisions? Is there a hash implementation
that's perfered for AAs?
bool isNull;
T value;
bool opEquals(Nullable!T other) {
if(this.isNull != other.isNull) return false;
// Any two nulls are equal.
if(isNull) return true;
return this.value == other.value;
}
}
auto n1 = Nullable!int(true, 3);
auto n2 = Nullable!int(true, 4);
writeln(n1
On Sunday, 31 July 2016 at 15:30:15 UTC, LaTeigne wrote:
On Sunday, 31 July 2016 at 15:21:01 UTC, Jack Stouffer wrote:
Is it really a problem? What are the pitfalls of defining one
but not the other?
iirc usage in an AA requires both.
But D provides a default toHash for every type if it's no
On Sunday, 31 July 2016 at 15:21:01 UTC, Jack Stouffer wrote:
Is it really a problem? What are the pitfalls of defining one
but not the other?
iirc usage in an AA requires both.
Is it really a problem? What are the pitfalls of defining one but
not the other?
On 6/30/16 8:30 AM, jj75607 wrote:
On Thursday, 30 June 2016 at 12:21:03 UTC, Steven Schveighoffer wrote:
On 6/30/16 6:26 AM, jj75607 wrote:
Hello!
I need to overload opEquals on shared class C
shared class C
{
override bool opEquals(Object o) { return false; }
}
But compilation fails
On Thursday, 30 June 2016 at 12:21:03 UTC, Steven Schveighoffer
wrote:
On 6/30/16 6:26 AM, jj75607 wrote:
Hello!
I need to overload opEquals on shared class C
shared class C
{
override bool opEquals(Object o) { return false; }
}
But compilation fails with the message:
Error: function
On 6/30/16 6:26 AM, jj75607 wrote:
Hello!
I need to overload opEquals on shared class C
shared class C
{
override bool opEquals(Object o) { return false; }
}
But compilation fails with the message:
Error: function f700.C.opEquals does not override any function, did you
mean to override
Hello!
I need to overload opEquals on shared class C
shared class C
{
override bool opEquals(Object o) { return false; }
}
But compilation fails with the message:
Error: function f700.C.opEquals does not override any function,
did you mean to override 'object.Object.opEquals'?
On Sunday, 21 February 2016 at 07:58:42 UTC, Jonathan M Davis
wrote:
opEquals still works with const and immutable
if it's legal to use a class as the key in an AA, it's a bug
have a working version of the PR
hasn't even been looked at yet from what I can tell,
and it's
On Sunday, February 21, 2016 04:25:59 SimonN via Digitalmars-d-learn wrote:
> Hi,
>
> immutable class A {
> int i;
> this(int arg) { i = arg; }
> override bool opEquals(Object rhsObj)
> {
> auto rhs = ca
Hi,
immutable class A {
int i;
this(int arg) { i = arg; }
override bool opEquals(Object rhsObj)
{
auto rhs = cast (immutable(A)) rhsObj;
return rhs && i == rhs.i;
}
}
Error by dmd 2.070:
./immutclass.d(4
ven if you could, there is no
such implementation in Object and, therefore, nothing to
override.
Templated functions can be used as overloads, though, but I'm
not sure off the top of my head if the compiler accepts
templated opEquals on classes at all. My guess is no, but you
can find out
On Friday, 29 January 2016 at 15:00:59 UTC, pineapple wrote:
With this bit of code, the first method seems to work fine -
things go as expected. But I get a compile error with the
second method, and I'm not sure how else to write this.
override bool opEquals(Object value)
It also occurred to me to do something like this, but it isn't
accepted either.
override bool opEquals(T)(T value){
return this.equals(value);
}
With this bit of code, the first method seems to work fine -
things go as expected. But I get a compile error with the second
method, and I'm not sure how else to write this.
override bool opEquals(Object value) const{
return this.equals(cast(typeof(this))
or is for.
Regardless, as the code posted by Ali indicates, the free function opEquals
that gets called by == for classes does check whether they're the same
object first by using the is operator, so all of the other checking is only
done if they're not the same object.
- Jonathan M Davis
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
On 11/17/2015 12:40 AM, MichaelZ wrote:
> In http://dlang.org/operatoroverloading.html#eqcmp it is
stated that
>
> "If opEquals is not specified, the compiler provides a
default version
> that does membe
On 11/17/15 3:25 PM, user123ABCabc wrote:
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
if (typeid(a) == typeid(b)) return a.opEquals(b);
Wow this is terrible to compare two objects in D. The line I quoted
means that two TypeInfoClass are likely to be allocated, right ?
On Tuesday, 17 November 2015 at 19:44:36 UTC, Ali Çehreli wrote:
if (typeid(a) == typeid(b)) return a.opEquals(b);
Wow this is terrible to compare two objects in D. The line I
quoted means that two TypeInfoClass are likely to be allocated,
right ?
But usually when comparing objects one
On 11/17/2015 12:40 AM, MichaelZ wrote:
> In http://dlang.org/operatoroverloading.html#eqcmp it is stated that
>
> "If opEquals is not specified, the compiler provides a default version
> that does member-wise comparison."
>
> However, doesn't this only apply to s
In http://dlang.org/operatoroverloading.html#eqcmp it is stated
that
"If opEquals is not specified, the compiler provides a default
version that does member-wise comparison."
However, doesn't this only apply to structs, and not objects?
The default behaviour of opEquals fo
On 05/05/2015 04:30 PM, Manfred Nowak wrote:
> On Tuesday, 5 May 2015 at 05:26:17 UTC, anonymous wrote:
>
>> because `c is c`
>
> Thanks. One can see this documented in
>http://dlang.org/operatoroverloading.html#equals
>
> But
> 1: how can one override this behavior
There is now way in D othe
On Tuesday, 5 May 2015 at 05:26:17 UTC, anonymous wrote:
because `c is c`
Thanks. One can see this documented in
http://dlang.org/operatoroverloading.html#equals
But
1: how can one override this behavior
2: what is the design reason for this
Especially: how can one implement side effects o
On Tuesday, 5 May 2015 at 04:09:03 UTC, Manfred Nowak wrote:
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
because `c is c`
class C{
override bool opEquals( Object o){
return true;
}
}
unittest{
auto c= new C;
assert( c == c);
}
`rdmd --main -unittest -cov' shows, that opEquals is not
executed. Why?
-manfred
On Tuesday, 25 November 2014 at 03:42:50 UTC, Eric wrote:
I'm finding it really hard to write robust classes in D
due to all the problems with Object.
I wish Object didn't have any methods. One thing I do is kinda
act as if it didn't and make my own interfaces instead.
Is it correct to replace '==' with 'is'?
It's not that it's inherently unsafe. The problem is a
combination of the
fact that stuff in druntime that pre-existed @safe hasn't been
made @safe
yet (particularly, stuff in TypeInfo) and the fact that Object
shouldn
in java endangers the GC?
>
> Is it correct to replace '==' with 'is'?
It's not that it's inherently unsafe. The problem is a combination of the
fact that stuff in druntime that pre-existed @safe hasn't been made @safe
yet (particularly, stuff in Type
@safe
class Y { }
@safe
class X { }
@safe
class Z
{
int x;
this()
{
if (typeid(X) == typeid(Y)) x = 1; // Compile Error
else x = 2;
}
}
void main() { new Z; }
// test.d(19): Error: safe function 'test.Z.this'
// cannot call system function 'object.opEquals'
I
object to both (0,1) and (1,0) not
being stored.
An AA, on the other hand, really shouldn't care about equivalence, only
equality.
This means, an AA which uses opCmp for collisions may get to a point where
opCmp returns 0, then has to additionally call opEquals defensively. I
d
1 - 100 of 207 matches
Mail list logo
