On 5/7/23 10:55, Chris Piker wrote:

> According to dmd 2.103, alias this is
> deprecated for classes, so I'd like to correct the problem.

alias this is for implicit type conversions, which can be achieved explicitly as well. Given the following old code:

class C {
    int* result;

    alias result this;
}

void foo(int*) {
}

auto main() {
    auto c = new C();

    // Implicit type conversion from C to int*:
    foo(c);
}

One can use a member function instead:

class C {
    int* result;

    auto asIntPtr() {
        return result;
    }
}

void foo(int*) {
}

auto main() {
    auto c = new C();

    // The same type conversion is now explicit:
    foo(c.asIntPtr);
}

Ali

On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
> auto main() {
>     auto c = new C();
>
>     // The same type conversion is now explicit:
>     foo(c.asIntPtr);
> }
>
Hi Ali

Ah, very clear explanation, thanks!  So basically to fix the problem I just delete the alias this line from dpq2, see what unit tests and app code it breaks, then fix each of those.  Actually seems straightforward, for a limited code base anyway.

On a side note, with all the free help you've provided, it's about time I gave back.  Since I've no free time or expertise to offer, I picked up a hardcover copy of "Programming in D" for a bright young programming student I know in appreciation.

Cheers,

On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
> alias this is for implicit type conversions, which can be achieved explicitly as well.

Open question to everybody: What you're opinion on using opCast for this? Since it's a type conversion, it seems fitting to me.

And another suggestion: Wrap the class in a struct that has visibility on the class members via the "package" access specifier and continue using "alias this".

On Sunday, 7 May 2023 at 21:04:05 UTC, Inkrementator wrote:
> On Sunday, 7 May 2023 at 18:19:04 UTC, Ali Çehreli wrote:
>> alias this is for implicit type conversions, which can be achieved explicitly as well.
>
> Open question to everybody: What you're opinion on using opCast for this? Since it's a type conversion, it seems fitting to me.
>
> And another suggestion: Wrap the class in a struct that has visibility on the class members via the "package" access specifier and continue using "alias this".

Hi Inkrementator

In this case, ResponseContainer is already a wrapper structure, so on the surface, putting a wrapper on a wrapper feels like over-engineering.

On the other hand, your first suggestion of using opCast() does seem like a reasonable choice to me.  Can you provide a short code snippet using opCast to achieve the same result?

On 5/7/23 13:44, Chris Piker wrote:

> to fix the problem I
> just delete the alias this line from dpq2, see what unit tests and app
> code it breaks, then fix each of those.

Yes but I neglected the lvalue/rvalue issue. In some cases the code won't compile if the return type of the newly written explicit function is not 'ref'. For example, the 'ref' below is essential for the following use case:

class C {
    int* result;

    // HERE
    ref asIntPtr() {
        return result;
    }
}

auto main() {
    auto c = new C();

    int i;
    c.asIntPtr = &i;
    assert(c.result == &i);
}

> "Programming in D" for a bright young programming
> student I know in appreciation.

Very kind of you! :)

Ali

On Wed, May 10, 2023 at 03:24:48PM +0000, Chris Piker via Digitalmars-d-learn wrote: [...]
> It's off topic, but I forget why managing memory for rvalues* was pushed onto the programmer and not handled by the compiler.  I'm sure there is a good reason but it does seem like a symmetry breaking requirement.
> 
> --
> *or was it lvalues, I can never keep the two separate.  Wish the some other terminology was adopted long ago, such as "named" vs. "ephemeral".

	x   =   y;
	^       ^
	|       |
	lvalue  rvalue

An lvalue is simply something that can appear on the *l*eft side of an assignment statement, and an rvalue is something that appears on the *r*ight side of an assignment statement.

It seems trivially obvious, but has far-reaching consequences. For one thing, to be an lvalue means that you must be able to assign a value to it. I.e., it must be a variable that exists somewhere in memory; `1 = x;` is illegal because `1` is a literal with no memory associated with it, so you cannot assign a new value to it.

For something to be an rvalue means that it's a value like `1` that may not necessarily have a memory address associated with it. For example, the value of a computation is an rvalue:

	// This is OK:
	x = y + 1;

	// This is not OK:
	(y + 1) = x;

The value of a computation cannot be assigned to, it makes no sense. Therefore, given an rvalue, you are not guaranteed that assignment is legal.

Note however, that given an lvalue, you can always get an rvalue out of it. In the first example above, `y` can be an lvalue because it's a variable with a memory location. However, it can also be used as an rvalue.  Or, if you like, `x = y;` contains an implicit "cast" of y to an rvalue.  But you can never turn an rvalue back into an lvalue.


T

-- 
It's bad luck to be superstitious. -- YHL

On Wednesday, 10 May 2023 at 16:01:40 UTC, H. S. Teoh wrote:
> 	x   =   y;
> 	^       ^
> 	|       |
> 	lvalue  rvalue
>
...
> 	// This is OK:
> 	x = y + 1;
>
> 	// This is not OK:
> 	(y + 1) = x;

Thanks for the clear explanation.

My problem with the terms lvalue and rvalue is much more basic, and is just a personal one that only affects probably 0.1% of people.  I just can't keep left vs. right straight in real life.  "Right" in my head always means "correct".

My daughter hates it when I'm telling her which way to turn the car since I've said the wrong direction so many times. :)