Re: Proper way to handle "alias this" deprecation for classes
On Wed, May 10, 2023 at 10:57:13PM +, Chris Piker via Digitalmars-d-learn wrote: > On Wednesday, 10 May 2023 at 20:25:48 UTC, H. S. Teoh wrote: > > On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via > > Digitalmars-d-learn wrote: [...] > > I also suffer from left/right confusion, and always have to pause to > > think about which is the right(!) word before uttering it. > Oh, I though was the only one with that difficulty. Glad to hear I'm > not alone. :-) :-) > I have a tendency to think of things by their purpose when programming > but not by their location on the line or page. So terms such as > "writable" versus "ephemeral" or "addressable" versus "temporary" (or > "register"), make so much more sense to me. Yeah TBH I was never a fan of the lvalue/rvalue terminology. In a hypothetical language where the arguments to an assignment operator is reversed, the terminology would become needlessly confusing. E.g., if there was an operator `X => Y;` that means "assign the value of X to Y", then the roles of lvalues/rvalues would be reversed. > Back on the ref issue for a moment... I'd imagine that asking the > compiler to delay creating a writable variable until it finds out that > a storage location is actually needed by subsequent statements, is a > tall order. So D chose to introduce programmers to lvalues and rvalues > head-on, instead of creating a leaky abstraction. It depends on how you look at it. The very concept of a variable in memory is actually already an abstraction. Modern compilers may enregister variables or even completely elide them. Assignments may be reordered, and the CPU may execute things out-of-order (as long as semantics are preserved). Intermediate values may not get stored at all, but get folded into the larger computation and perhaps merged with some other operation with the resulting compound operation mapped to a single CPU instruction, etc.. So in that sense the compiler is quite capable of figuring out what to do... But what it can't do is read the programmer's mind to deduce the intent of his code. Exact semantics must be somehow conveyed to the compiler, and sad to say humans aren't very good at being exact. Often we *think* we know exactly what the computation is, but in reality we gloss over low-level details that will make a big difference in the outcome of the computation in the corner cases. The whole rvalue/lvalue business is really more a way of conveying to the compiler what exactly must happen, rather than directly corresponding to any actual feature in the underlying physical machine. T -- Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. -- Gene Wirchenko
Re: Proper way to handle "alias this" deprecation for classes
On Wednesday, 10 May 2023 at 20:25:48 UTC, H. S. Teoh wrote: On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via Digitalmars-d-learn wrote: [...] I also suffer from left/right confusion, and always have to pause to think about which is the right(!) word before uttering it. Oh, I though was the only one with that difficulty. Glad to hear I'm not alone. :-) I have a tendency to think of things by their purpose when programming but not by their location on the line or page. So terms such as "writable" versus "ephemeral" or "addressable" versus "temporary" (or "register"), make so much more sense to me. Back on the ref issue for a moment... I'd imagine that asking the compiler to delay creating a writable variable until it finds out that a storage location is actually needed by subsequent statements, is a tall order. So D chose to introduce programmers to lvalues and rvalues head-on, instead of creating a leaky abstraction.
Re: Proper way to handle "alias this" deprecation for classes
On Wed, May 10, 2023 at 07:56:10PM +, Chris Piker via Digitalmars-d-learn wrote: [...] > 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. :) I also suffer from left/right confusion, and always have to pause to think about which is the right(!) word before uttering it. :-D Would compass directions be more helpful? (wvalue vs. evalue) Or would it suffer from the same problem? (One could retroactively rationalize it as *w*ritable value vs. *e*phemeral value. :-P) T -- By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth
Re: Proper way to handle "alias this" deprecation for classes
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. :)
Re: what is the aftermath of dip74
On 11/05/2023 6:23 AM, Ferhat Kurtulmuş wrote: Thank you Rikki for the clarification. I think d need this without ugly workarounds. Yeah we do. Reference counting is expensive, and modern backends have the capability to elide pairs of calls. So this would be a massive improvement just from the perspective of performance alone.
Re: what is the aftermath of dip74
On Wednesday, 10 May 2023 at 18:15:36 UTC, Richard (Rikki) Andrew Cattermole wrote: We do not, no. Reference counting is not currently in the language, although you can fake it with structs. Its a huge shame, but it should be added at some point because the compiler would tell the backend that it is possible to elide pair calls. However it'll have to wait for the DIP queue to reopen (slight process adjustment to make things easier is incoming). Thank you Rikki for the clarification. I think d need this without ugly workarounds.
Re: what is the aftermath of dip74
We do not, no. Reference counting is not currently in the language, although you can fake it with structs. Its a huge shame, but it should be added at some point because the compiler would tell the backend that it is possible to elide pair calls. However it'll have to wait for the DIP queue to reopen (slight process adjustment to make things easier is incoming).
Re: Proper way to handle "alias this" deprecation for classes
On Wed, May 10, 2023 at 03:24:48PM +, 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
Re: Proper way to handle "alias this" deprecation for classes
On Wednesday, 10 May 2023 at 14:42:50 UTC, Inkrementator wrote: On Sunday, 7 May 2023 at 21:12:22 UTC, Chris Piker wrote: https://gist.github.com/run-dlang/9b7aec72710b1108fc8277789776962a Thanks for posting that. Reading over the code I'm reminded that I never cared whether something was an rvalue or lvalue before writing D code. 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".
Re: Proper way to handle "alias this" deprecation for classes
On Sunday, 7 May 2023 at 21:12:22 UTC, Chris Piker wrote: 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? I've never used it, and particularly I know that I don't know whether making the the return type of opCast ref can lead to issues down the road and whether the template specialization is dangerous, as it will trigger for all types implicitly convertible to int* (whatever they are) Another potential future pitfall I discovered is that code might break if you change your class into a struct. Code example is in a gist since the system thinks I've added HTML entities to it and won't let me post it: https://gist.github.com/run-dlang/9b7aec72710b1108fc8277789776962a
std.net.curl and POST-requests with files
The [std.net.curl](https://dlang.org/phobos/std_net_curl.html) module provides these functions: ```d T[] post(T = char, PostUnit)(const(char)[] url, const(PostUnit)[] postData, HTTP conn = HTTP()) T[] post(T = char)(const(char)[] url, string[string] postDict, HTTP conn = HTTP()) ``` How can I use it if I want to transfer a file with some name? (No problem with regular text.)
