I noticed that opOpAsign allows you to return a value...

this means I can do this (return a node from my list class when adding a new node)
```
anode = alist ~= &someData;
```
to me this looks a little unusual (but to be fair I can live with it)

being as when its used like this:
```
alist ~= &someData;
```
you need to find out what the ~ operator does anyway, I don't think it harms readability

any thoughts?

On Wednesday, November 7, 2018 9:28:19 PM MST Codifies via Digitalmars-d- learn wrote:
> I noticed that opOpAsign allows you to return a value...
>
> this means I can do this (return a node from my list class when
> adding a new node)
> ```
> anode = alist ~= &someData;
> ```
> to me this looks a little unusual (but to be fair I can live with
> it)
>
> being as when its used like this:
> ```
> alist ~= &someData;
> ```
> you need to find out what the ~ operator does anyway, I don't
> think it harms readability
>
> any thoughts?

It's common practice in C++ to have the various assignment operators return a reference to the object being assigned to so that the operations can be chained, and I don't see why the situation in D would be any different. But if for whatever reason, you don't want to do the same with your types, you can always just make those operators void. Either way, the fact that an assignment operator returns a reference to the object doesn't require you to then actually use it for anything. It just allows folks to do so if they think that it's appropriate in a particular piece of code. Sometimes, it's useful; often it isn't, but if the return type is void, then you can't do it even in the cases where it would be useful.

- Jonathan M Davis

On Wednesday, November 7, 2018 10:45:07 PM MST Jonathan M Davis via Digitalmars-d-learn wrote:
> On Wednesday, November 7, 2018 9:28:19 PM MST Codifies via Digitalmars-d-
>
> learn wrote:
> > I noticed that opOpAsign allows you to return a value...
> >
> > this means I can do this (return a node from my list class when
> > adding a new node)
> > ```
> > anode = alist ~= &someData;
> > ```
> > to me this looks a little unusual (but to be fair I can live with
> > it)
> >
> > being as when its used like this:
> > ```
> > alist ~= &someData;
> > ```
> > you need to find out what the ~ operator does anyway, I don't
> > think it harms readability
> >
> > any thoughts?
>
> It's common practice in C++ to have the various assignment operators return a reference to the object being assigned to so that the operations can be chained, and I don't see why the situation in D would be any different. But if for whatever reason, you don't want to do the same with your types, you can always just make those operators void. Either way, the fact that an assignment operator returns a reference to the object doesn't require you to then actually use it for anything. It just allows folks to do so if they think that it's appropriate in a particular piece of code. Sometimes, it's useful; often it isn't, but if the return type is void, then you can't do it even in the cases where it would be useful.

Rereading what you wrote, are you asking whether it's reasonable to return a value instead of a reference? Personally, I don't think that that's good design at all, but I also don't see any reason for the compiler to prevent it.

Personally, I think that the default design should be to return by ref. Returning void is less than ideal but isn't necessarily bad, depending on the situation (especially if we're not talking about a general purpose library). However, I expect that returning non-void by value rather than by ref is rarely -if ever - going to be a good design choice. It's just going to be confusing and not particularly useful.

- Jonathan M Davis

On Thursday, 8 November 2018 at 06:01:57 UTC, Jonathan M Davis wrote:
> On Wednesday, November 7, 2018 10:45:07 PM MST Jonathan M Davis via Digitalmars-d-learn wrote:
>> [...]
>
> Rereading what you wrote, are you asking whether it's reasonable to return a value instead of a reference? Personally, I don't think that that's good design at all, but I also don't see any reason for the compiler to prevent it.
>
> Personally, I think that the default design should be to return by ref. Returning void is less than ideal but isn't necessarily bad, depending on the situation (especially if we're not talking about a general purpose library). However, I expect that returning non-void by value rather than by ref is rarely -if ever - going to be a good design choice. It's just going to be confusing and not particularly useful.
>
> - Jonathan M Davis

NB its not returning a ref to the list, its returning the newly created node when you use the operator you add a type to the list, so it possibly wouldn't be that much use for chaining?

On Thursday, November 8, 2018 2:15:43 AM MST Codifies via Digitalmars-d-learn wrote:
> On Thursday, 8 November 2018 at 06:01:57 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, November 7, 2018 10:45:07 PM MST Jonathan M Davis
> >
> > via Digitalmars-d-learn wrote:
> >> [...]
> >
> > Rereading what you wrote, are you asking whether it's reasonable to return a value instead of a reference? Personally, I don't think that that's good design at all, but I also don't see any reason for the compiler to prevent it.
> >
> > Personally, I think that the default design should be to return by ref. Returning void is less than ideal but isn't necessarily bad, depending on the situation (especially if we're not talking about a general purpose library). However, I expect that returning non-void by value rather than by ref is rarely -if ever - going to be a good design choice. It's just going to be confusing and not particularly useful.
> >
> > - Jonathan M Davis
>
> NB its not returning a ref to the list, its returning the newly created node when you use the operator you add a type to the list, so it possibly wouldn't be that much use for chaining?

The normal thing to do with any of the assignment operators is to return a reference to the object you're assigning to. Doing much of anything else other than returning void (and thus not allowing chaining) would be pretty abnormal. If it's appropriately documented, having an assignment operator return something else could certainly be made to work, but I expect that most programmers would consider it to be a backwards API.

- Jonathan M Davis