On Wednesday, 5 June 2024 at 17:42:20 UTC, Quirin Schroll wrote:
>except for toString
Well, we could make it compatible with @nogc:
void toString(scope void delegate(in char[]) pure nothrow @nogc sink) const scope pure nothrow @nogc
June 06 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 06/06/2024 6:10 AM, H. S. Teoh wrote:
> We've talked about ProtoObject literally for years. When are we going
> to actually implement it?
I'm getting to that point with a number of other things like @notls (will be talking about it at next meeting).
Custom root classes are not on my list currently for DIP writing, but it is something I want. I'm blocked on them by reference counting, but if somebody else wants to do it, go for it!
|
June 06 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | On Wednesday, 5 June 2024 at 17:42:20 UTC, Quirin Schroll wrote: >except for Well, we could make it compatible with @nogc:
|
June 06 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On Friday, 26 April 2024 at 22:55:32 UTC, Jonathan M Davis wrote: >And given that If it’s for the |
June 06 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ogi | On Thursday, 6 June 2024 at 08:00:40 UTC, Ogi wrote: >On Wednesday, 5 June 2024 at 17:42:20 UTC, Quirin Schroll wrote: >except for Well, we could make it compatible with @nogc:
That’s actually a big no. Such a You need 16 overloads, all but 1 of them In cases like What would be needed is a notion of attribute variables, similar to how
makes sense. Overriders would be bound to the same relative respect to attributes. The correct choice is a template, but templates cannot be virtual. |
June 06 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | On Thursday, 6 June 2024 at 09:57:29 UTC, Quirin Schroll wrote: >On Thursday, 6 June 2024 at 08:00:40 UTC, Ogi wrote: >
Is this serious? I mean it's not and inside joke about how ridiculous D function signatures are getting? The D world has gone mad. |
June 06 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | >
> I talked to Walter and we agreed that the best way forward is probably to deprecate these member functions and remove them in the next edition.
What are the problems when getting rid all of them?
Currently, below codes are compiled with correct result, why not emulated without those functions?
struct F
{
string s;
int i;
}
void main()
{
import std.conv : to;
F f1 = {s:"1", i:1};
F f2 = {s:"2", i:2};
const c = int.min; // f2 > f1; onlineapp.d(13): Error: need member function `opCmp()` for struct `F` to compare
const e = f2 == f1;
const s = f2.to!string;
const h = hashOf(f2); // f2.toHash(); onlineapp.d(16): Error: no property `toHash` for `f2` of type `onlineapp.F`
import std.algorithm, std.stdio, std.file, std.range;
writeln("c=", c, ", e=", e, ", s=", s, ", h=", h);
}
|
June 07 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to An Pham | On Thursday, 6 June 2024 at 20:03:09 UTC, An Pham wrote:
>>
>> I talked to Walter and we agreed that the best way forward is probably to deprecate these member functions and remove them in the next edition.
>
> What are the problems when getting rid all of them?
Code breakage.
|
June 07 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to claptrap | On Thursday, 6 June 2024 at 17:30:07 UTC, claptrap wrote: >On Thursday, 6 June 2024 at 09:57:29 UTC, Quirin Schroll wrote: >On Thursday, 6 June 2024 at 08:00:40 UTC, Ogi wrote: >
Is this serious? I mean it's not and inside joke about how ridiculous D function signatures are getting? The D world has gone mad. The |
June 07 Re: Object.toString, toHash, opCmp, opEquals | ||||
---|---|---|---|---|
| ||||
Posted in reply to Quirin Schroll | On Thursday, 6 June 2024 at 09:57:29 UTC, Quirin Schroll wrote: >You need 16 overloads, all but 1 of them There really should be only one interface provided each method with no lambda function arguments in Object by default:
If there is need to have better constraints, people can just extend the interface and narrow the declaration:
People that need that enforcement, can in worst case do a cast down to interface that satisfies their attribute requirements, and if object doesn't satisfy it, then handle it. For lambda ones, there should be some other solution. In worst case, default provided interface could have narrowest possible configuration, i.e. @safe @nogc pure const, from which people could widen the configuration in each interface extension. |