Menu
Search

Forums

Forum Index

June 06
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to H. S. Teoh		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to H. S. Teoh


Reply
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
Gravatar of OgiPosted by Ogi
in reply to Quirin Schroll		Reply
Ogi
Gravatar of Ogi
Posted in reply to Quirin Schroll


Reply

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
Gravatar of Quirin SchrollPosted by Quirin Schroll
in reply to Jonathan M Davis		Reply
Quirin Schroll
Gravatar of Quirin Schroll
Posted in reply to Jonathan M Davis


Reply

On Friday, 26 April 2024 at 22:55:32 UTC, Jonathan M Davis wrote:

>

And given that Object really doesn't need to have any of these functions, we likely would have removed them years ago if it weren't for the fact that something like that would break code (in large part due to the override keyword; a lot of the code would have worked just fine with those functions being removed from Object if the derived classes didn't have to have override, which will then become an error when the base class version of the function is removed). Andrei also proposed ProtoObject as a way to change the class hierarchy so that we could remove these functions (as well as the monitor) from classes without breaking code built on top of Object. So, we've known for years that we could fix this problem if we could just remove these functions from Object.

If it’s for the override keyword alone, the compiler could recognize that a class overrides a formerly present Object method and issue a deprecation instead of an error while pretending these particular uses override.

June 06
Gravatar of Quirin SchrollPosted by Quirin Schroll
in reply to Ogi		Reply
Quirin Schroll
Gravatar of Quirin Schroll
Posted in reply to Ogi


Reply

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 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

That’s actually a big no. Such a toString can’t be used e.g. to append the characters to an array as that’s not a @nogc sink.

You need 16 overloads, all but 1 of them final, the non-final one without attributes. Then, derived classes could override the non-attributed version where the attributed versions (the final ones in Object) call the overridable one and do a little casting so that it’s possible. This sounds great on first glance, but the issue here is that this approach assumes that the toString implementation is essentially compatible with all attributes except for the sink call. While the default implementation in Object can have this property, overriders may not be, and if they’re not, there’s no error (or warning).

In cases like opApply, that approach works, but only because one can statically know that the implementation will respect attributes. For classes, due to overriding, one cannot.

What would be needed is a notion of attribute variables, similar to how inout is a type qualifier variable. Then,

void toString(scope void delegate(in char[]) xpure xnothrow @xnogc sink) const scope xpure xnothrow @xnogc;

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
Gravatar of claptrapPosted by claptrap
in reply to Quirin Schroll		Reply
claptrap
Gravatar of claptrap
Posted in reply to Quirin Schroll


Reply

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:

 > 
void toString(scope void delegate(in char[]) xpure xnothrow @xnogc sink) const scope xpure xnothrow @xnogc;

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
Gravatar of An PhamPosted by An Pham
in reply to Atila Neves		Reply
An Pham
Gravatar of An Pham
Posted in reply to Atila Neves


Reply
>
> 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
Gravatar of Atila NevesPosted by Atila Neves
in reply to An Pham		Reply
Atila Neves
Gravatar of Atila Neves
Posted in reply to An Pham


Reply
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
Gravatar of Quirin SchrollPosted by Quirin Schroll
in reply to claptrap		Reply
Quirin Schroll
Gravatar of Quirin Schroll
Posted in reply to claptrap


Reply

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:

 > 
void toString(scope void delegate(in char[]) xpure xnothrow @xnogc sink) const scope xpure xnothrow @xnogc;

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 x… attributes are not valid D code; I made them up on the spot. The DIP Argument dependent attributes proposes essentially that.

June 07
Gravatar of Alexandru ErmicioiPosted by Alexandru Ermicioi
in reply to Quirin Schroll		Reply
Alexandru Ermicioi
Gravatar of Alexandru Ermicioi
Posted in reply to Quirin Schroll


Reply

On Thursday, 6 June 2024 at 09:57:29 UTC, Quirin Schroll wrote:

>

You need 16 overloads, all but 1 of them final, the non-final one without attributes.

There really should be only one interface provided each method with no lambda function arguments in Object by default:

interface ToString {
    string toString();
}

If there is need to have better constraints, people can just extend the interface and narrow the declaration:

interface SafeNogcToString : ToString {
    string toString() @safe @nogc;
}

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.

« First   ‹ Prev
1 2 3 4 5
Next ›   Last »