Discussion Thread: DIP 1042--ProtoObject--Community Review Round 1 (page 7)

On Saturday, 15 January 2022 at 05:07:02 UTC, Elronnd wrote: > On Friday, 14 January 2022 at 23:51:37 UTC, Ola Fosheim Grøstad wrote: >> Yet x < x+1 does not hold for any types in D. So much for ordering principles... > > Hm, we do have !(x > x+1) for floats... That is equivalent to x <= x+1 so that holds for numerical floats, but x < x+1 does not.

On Saturday, 15 January 2022 at 00:56:46 UTC, Greg Strong wrote: > On Saturday, 15 January 2022 at 00:34:03 UTC, Adam Ruppe wrote: >> On Saturday, 15 January 2022 at 00:09:38 UTC, Greg Strong wrote: >>> Huh? Please expound. Pretty sure x < x+1 for plenty of types in D, or I'm sure I would have noticed by now! >> >> Consider the case of int.max + 1.... > > Ok, fair enough, but given that that issue applies to, like, almost every integer format in, like, every programming language, I just assumed Ola was rather referring to some D-specific problem. If this is indeed the issue to which he was referring, well, that's just trolling :D No. It is D specific. It hold for signed ints in C++ and I believe it holds in Zig too.

On 11.01.22 21:44, Timon Gehr wrote: > > >> you want to implement something more >> esoteric, that's fine, you can define your own interface. > > There we go. You think anything that does not fit those arbitrarily defined interfaces is "esoteric". That's precisely my main issue. This is not true. If someone's use case has to be dubbed "esoteric", it would rather be to use qualifiers beyond `@safe` in object-oriented code. BTW: `pure` toHash can also be rather problematic in case it returns the address of the object as an integer (as it currently does by default). Pure code should not depend on GC memory addresses.

On Saturday, 15 January 2022 at 06:20:03 UTC, Ola Fosheim Grøstad wrote: >> Hm, we do have !(x > x+1) for floats... > > That is equivalent to x <= x+1 so that holds for numerical floats !(x > x+1) works for nan too, which is why I wrote it the way I did. NB. I believe d used to have operators like !> specifically for this reason.

On Saturday, 15 January 2022 at 08:33:45 UTC, Timon Gehr wrote: > `pure` toHash can also be rather problematic in case it returns the address of the object as an integer (as it currently does by default). Pure code should not depend on GC memory addresses. There has been a comment about that in object.d for over a decade; in that time, no one has made a compacting GC. More practically, if somebody does write a compacting GC, it will be child's play for them to go and add a 'hash' field to Object and change the implementations of cmp and toHash. (Obviously userspace code should not depend on such mechanisms, but for druntime, what is the problem?)

January 15, 2022

Re: Discussion Thread: DIP 1042--ProtoObject--Community Review Round 1

Posted by Alexandru Ermicioi
in reply to Adam Ruppe

Permalink

Alexandru Ermicioi

Posted in reply to Adam Ruppe

Permalink

On Friday, 14 January 2022 at 23:34:24 UTC, Adam Ruppe wrote:
> On Friday, 14 January 2022 at 22:45:53 UTC, Alexandru Ermicioi wrote:
>> Imho interfaces could be smth like this:
>>
>> ```d
>> interface Equals(U) {
>>   bool equals(U other);
>
>
> No const?

That was an example ofc. Equals method could be overloaded with const and immutable version in there too, or have separate iface.

> Note that opEquals like this already works on dmd master with the specific class and attributes.

From what I'm aware, with couple of compiler hacks, while this offers no hacks.

Anyway, if there is no possibility to make friends inheritance and method attributes easily, then best is to just remove them from Object and be done with it.

As a replacement there could be some interfaces that represent the different operations, with no attribute on them, so they can be easily subtyped with stronger guarantees, just like how it can be done right now with object's equals or cmp methods. People that want a specific attribute will just define a subinterface that they need and use it. For standard lib, for example sort alg. it should just accept the concrete type of comparable, instead of root comparable interface.

P.S. Can't we enhance compiler and bake the attribute info into interface itself, and then allow downcasting it to an interface with specific subset of attribtues?
I.e. say we have safe nothrow nogc equals interface. We then in some random code could downcast safely to safe nogc equals interface?
This might solve the problem a bit.

On Saturday, 15 January 2022 at 09:24:43 UTC, Elronnd wrote:

!(x > x+1) works for nan too, which is why I wrote it the way I did. NB. I believe d used to have operators like !> specifically for this reason.

Yes, D had some improvements in this area. Floats are kinda difficult to reason about in a principled manner though. It is easier judge floats as "probabilistic numbers" or "numbers with an amount of noise" than traditional mathematical objects.

Anyway, my main point here is that all these "principled" discussions about comparison will be of limited use if the compiler cannot generally reason about the magnitude of the fields you use to build complex objects. It becomes mostly syntactical changes and not really not worth a breaking change.

If the compiler is not allowed to flag integer overflows as an error at compile time or run time, then reasoning soundly about magnitude will stay difficult. Fix that first, then we can look at making changes to comparisons that enables more compiler-smarts! That should be done in a separate DIP though.

And that is the problem with this DIP, it doesn't move on anything that matters and where it adds an improvement (removing the mutex) the compiler is already free to remove it if it isn't used. So there is no pressing need to change the language spec in this area.

On 15.01.22 10:34, Elronnd wrote: > On Saturday, 15 January 2022 at 08:33:45 UTC, Timon Gehr wrote: >> `pure` toHash can also be rather problematic in case it returns the address of the object as an integer (as it currently does by default). Pure code should not depend on GC memory addresses. > > There has been a comment about that in object.d for over a decade; in that time, no one has made a compacting GC. More practically, if somebody does write a compacting GC, it will be child's play for them to go and add a 'hash' field to Object and change the implementations of cmp and toHash. > > (Obviously userspace code should not depend on such mechanisms, but for druntime, what is the problem?) The issue is not that addresses might change, it's that they depend on global state. Therefore, e.g., iteration order for an associative array will depend on global state too. It's just not `pure`.

On 15.01.22 10:34, Elronnd wrote: > More practically, if somebody does write a compacting GC, it will be child's play for them to go and add a 'hash' field to Object and change the implementations of cmp and toHash. Seems like that would make class object construction impure.

On Saturday, 15 January 2022 at 10:15:16 UTC, Timon Gehr wrote: > The issue is not that addresses might change, it's that they depend on global state. Therefore, e.g., iteration order for an associative array will depend on global state too. It's just not `pure`. It seems to me that any data passed from an impure function to a pure one will depend on global state. And d has no problem with pure functions doing things to pointers that are passed to them anyway. So the current state seems fine (or, at least, fully consistent).

Forums