On 4/26/2024 11:28 AM, Per Nordlöw wrote:
> Shouldn't some or all of them be qualified as scope aswell?

I did think of that, but also figured if I can't get const, scope is dead in the water, too.

On Friday, 26 April 2024 at 08:43:46 UTC, Jonathan M Davis wrote:
> The ideal situation here is that none of these functions are on Object at all. They really aren't useful there, because it's not particularly useful or necessary to operate on Object. Some of the druntime code does, because it hasn't been templated yet, but once it has been, it won't need to operate on Object at all. At that point, we won't need to have any of these functions on Object, and Editions should give us the ability to remove them.

+1, this is the correct solution.

We've already had success templating the druntime opEquals lowering for classes [1]. We can and should do the same thing for the other Object methods.

[1] https://github.com/dlang/druntime/pull/3665

On Saturday, 27 April 2024 at 16:35:41 UTC, Paul Backus wrote:
> On Friday, 26 April 2024 at 08:43:46 UTC, Jonathan M Davis wrote:
>> The ideal situation here is that none of these functions are on Object at all. They really aren't useful there, because it's not particularly useful or necessary to operate on Object. Some of the druntime code does, because it hasn't been templated yet, but once it has been, it won't need to operate on Object at all. At that point, we won't need to have any of these functions on Object, and Editions should give us the ability to remove them.
>
> +1, this is the correct solution.
>
> We've already had success templating the druntime opEquals lowering for classes [1]. We can and should do the same thing for the other Object methods.
>
> [1] https://github.com/dlang/druntime/pull/3665

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.

On Wednesday, May 8, 2024 7:20:20 PM MDT Atila Neves via Digitalmars-d wrote:
> On Saturday, 27 April 2024 at 16:35:41 UTC, Paul Backus wrote:
> > On Friday, 26 April 2024 at 08:43:46 UTC, Jonathan M Davis
> >
> > wrote:
> >> The ideal situation here is that none of these functions are on Object at all. They really aren't useful there, because it's not particularly useful or necessary to operate on Object. Some of the druntime code does, because it hasn't been templated yet, but once it has been, it won't need to operate on Object at all. At that point, we won't need to have any of these functions on Object, and Editions should give us the ability to remove them.
> >
> > +1, this is the correct solution.
> >
> > We've already had success templating the druntime opEquals lowering for classes [1]. We can and should do the same thing for the other Object methods.
> >
> > [1] https://github.com/dlang/druntime/pull/3665
>
> 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.

Yay!

- Jonathan M Davis

On Thu, May 09, 2024 at 01:53:55AM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, May 8, 2024 7:20:20 PM MDT Atila Neves via Digitalmars-d 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.
> 
> Yay!
[...]

Finally!!  Should've done this years ago.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.

On Thursday, May 9, 2024 9:24:12 AM MDT H. S. Teoh via Digitalmars-d wrote:
> On Thu, May 09, 2024 at 01:53:55AM -0600, Jonathan M Davis via Digitalmars-d
wrote:
> > On Wednesday, May 8, 2024 7:20:20 PM MDT Atila Neves via Digitalmars-d
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.
> >
> > Yay!
>
> [...]
>
> Finally!!  Should've done this years ago.

Yeah, but issues with regards to code breakage have made it difficult to do cleanly. Editions should make it much more reasonable.

- Jonathan M Davis

On Thu, May 09, 2024 at 01:12:35PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, May 9, 2024 9:24:12 AM MDT H. S. Teoh via Digitalmars-d wrote:
> > On Thu, May 09, 2024 at 01:53:55AM -0600, Jonathan M Davis via Digitalmars-d
> wrote:
> > > On Wednesday, May 8, 2024 7:20:20 PM MDT Atila Neves via Digitalmars-d
> 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.
> > >
> > > Yay!
> >
> > [...]
> >
> > Finally!!  Should've done this years ago.
> 
> Yeah, but issues with regards to code breakage have made it difficult to do cleanly. Editions should make it much more reasonable.
[...]

Have editions been implementing in any shape/form yet?  Been curious about what it looks like, and how it works in practice.


T

-- 
I am Pentium of Borg. Division is futile; you will be approximated.

On Thursday, May 9, 2024 2:15:27 PM MDT H. S. Teoh via Digitalmars-d wrote:
> On Thu, May 09, 2024 at 01:12:35PM -0600, Jonathan M Davis via Digitalmars-d
wrote:
> > On Thursday, May 9, 2024 9:24:12 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> > > On Thu, May 09, 2024 at 01:53:55AM -0600, Jonathan M Davis via Digitalmars-d>
> > wrote:
> > > > On Wednesday, May 8, 2024 7:20:20 PM MDT Atila Neves via Digitalmars-d
> >
> > 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.
> > > >
> > > > Yay!
> > >
> > > [...]
> > >
> > > Finally!!  Should've done this years ago.
> >
> > Yeah, but issues with regards to code breakage have made it difficult to do cleanly. Editions should make it much more reasonable.
>
> [...]
>
> Have editions been implementing in any shape/form yet?  Been curious about what it looks like, and how it works in practice.

If I understand correctly, some changes have been made in dmd which are supposed to only be in effect with a new edition, but I don't think that the actual edition mechanism has been implemented yet. There's been a fair bit of going back and forth over the details of the proposal (at the moment, mostly how that would interact with dub), which could affect the implementation anyway.

At its most basic though, the core idea is that a module could be marked as being for a specific edition, and it would then be compiled with the rules for that edition regardless of which edition the code importing it uses (and that includes any templated code within the module). So, in theory, the code within that module would continue to work as it always has as new editions are released, meaning that breaking changes in future editions wouldn't affect it until that code was updated to be marked as being for a new edition, at which point, the maintainer would need to update it in whatever fashion was necessary to get it working properly with the new edition.

So, the reason that we could then make breaking changes with new editions would be because you can control which edition your code targets, making it so that those breaking changes don't affect you until you're ready to deal with them.

Unfortunately, because the program can only use one version of druntime, which would then need to be able to work with all editions, there are some things which we likely won't ever be able to change (like it sounds like we're probably going to be stuck with the monitor in Object), but we'll definitely be able to make more breaking changes than we can right now.

- Jonathan M Davis

On Wed, Jun 05, 2024 at 05:42:20PM +0000, Quirin Schroll via Digitalmars-d wrote:
> On Friday, 26 April 2024 at 18:28:00 UTC, Per Nordlöw wrote:
> > On Thursday, 25 April 2024 at 23:06:27 UTC, Walter Bright wrote:
> > > The prototypes are:
> > > 
> > > ```
> > > string toString();
> > > size_t toHash() @trusted nothrow;
> > > int opCmp(Object o);
> > > bool opEquals(Object o);
> > > ```
> > > 
> > > which long predated `const`. The trouble is, they should be:
> > 
> > Shouldn't some or all of them be qualified as scope aswell?
[...]
> However, I’m with Timon here, that those shouldn’t be forced onto the
> user.  Ideally, `Object` is empty (devoid of any functions) and there
> is an optional-to-inherit-from class or a mixin template that adds all
> those functions with some default implementation which is `@safe`,
> too.

We've talked about ProtoObject literally for years.  When are we going to actually implement it?


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth