Thread overview | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 14, 2009 const ref rvalues | ||||
---|---|---|---|---|
| ||||
I mentioned this deep in another thread, but I think it deserves its own thread. Can we get something like: void doStuff(T)(const ref T val) { // do stuff. } T getVal() { return someValue; } void main() { doStuff(getVal()); // Doesn't currently work. } For non-const ref parameters, it's understandable that passing rvalues in doesn't work because this is likely a bug that the compiler should catch. However, for const ref parameters, can't the compiler just implicitly put the value on the caller's stack frame and convert it to an lvalue rather than forcing the programmer to write the boilerplate to do this manually? This would result in: doStuff(getVal()); --> auto __temp = getVal(); doStuff(__temp); |
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha Wrote:
> I mentioned this deep in another thread, but I think it deserves its own thread. Can we get something like:
>
> void doStuff(T)(const ref T val) {
> // do stuff.
> }
>
> T getVal() {
> return someValue;
> }
>
> void main() {
> doStuff(getVal()); // Doesn't currently work.
> }
>
> For non-const ref parameters, it's understandable that passing rvalues in doesn't work because this is likely a bug that the compiler should catch. However, for const ref parameters, can't the compiler just implicitly put the value on the caller's stack frame and convert it to an lvalue rather than forcing the programmer to write the boilerplate to do this manually? This would result in:
>
> doStuff(getVal()); -->
>
> auto __temp = getVal();
> doStuff(__temp);
My vote for it.
|
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to Eldar Insafutdinov | Eldar Insafutdinov wrote:
> dsimcha Wrote:
>
>> I mentioned this deep in another thread, but I think it deserves its own
>> thread. Can we get something like:
>>
>> void doStuff(T)(const ref T val) {
>> // do stuff.
>> }
>>
>> T getVal() {
>> return someValue;
>> }
>>
>> void main() {
>> doStuff(getVal()); // Doesn't currently work.
>> }
>>
>> For non-const ref parameters, it's understandable that passing rvalues in
>> doesn't work because this is likely a bug that the compiler should catch.
>> However, for const ref parameters, can't the compiler just implicitly put the
>> value on the caller's stack frame and convert it to an lvalue rather than
>> forcing the programmer to write the boilerplate to do this manually? This
>> would result in:
>>
>> doStuff(getVal()); -->
>>
>> auto __temp = getVal();
>> doStuff(__temp);
>
> My vote for it.
Binding rvalues to const references was probably the single most hurtful design decisions for C++. I don't have time to explain now, but in short I think all of the problems that were addressed by rvalue references, and most of the aggravation within the design of rvalue references, are owed by that one particular conversion.
If we ever allow automatic conversion of an rvalue to a ref, we should know very well what we're doing.
Andrei
|
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha Wrote:
> I mentioned this deep in another thread, but I think it deserves its own thread. Can we get something like:
>
> void doStuff(T)(const ref T val) {
> // do stuff.
> }
>
> T getVal() {
> return someValue;
> }
>
> void main() {
> doStuff(getVal()); // Doesn't currently work.
> }
>
> For non-const ref parameters, it's understandable that passing rvalues in doesn't work because this is likely a bug that the compiler should catch. However, for const ref parameters, can't the compiler just implicitly put the value on the caller's stack frame and convert it to an lvalue rather than forcing the programmer to write the boilerplate to do this manually? This would result in:
>
> doStuff(getVal()); -->
>
> auto __temp = getVal();
> doStuff(__temp);
If T is a class, I agree it should work. If T is a struct, you'll need a stronger argument. Maybe scope const ref T would make sense. IMHO, non- scope ref T for structs is already a questionable practice, and I don't mind the compiler making that scenario tougher for me.
|
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha <dsimcha@yahoo.com> wrote:
> I mentioned this deep in another thread, but I think it deserves its own
> thread. Can we get something like:
>
> void doStuff(T)(const ref T val) {
> // do stuff.
> }
>
> T getVal() {
> return someValue;
> }
>
> void main() {
> doStuff(getVal()); // Doesn't currently work.
> }
>
> For non-const ref parameters, it's understandable that passing rvalues in
> doesn't work because this is likely a bug that the compiler should catch.
> However, for const ref parameters, can't the compiler just implicitly put the
> value on the caller's stack frame and convert it to an lvalue rather than
> forcing the programmer to write the boilerplate to do this manually? This
> would result in:
>
> doStuff(getVal()); -->
>
> auto __temp = getVal();
> doStuff(__temp);
I agree it hurts a lot. I faced the same problem implementing RefCounted: you can't return RefCounted object from one function and pass it by reference to another one. Passing it by value is not a good option.
|
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | Denis Koroskin wrote:
> On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha <dsimcha@yahoo.com> wrote:
>
>> I mentioned this deep in another thread, but I think it deserves its own
>> thread. Can we get something like:
>>
>> void doStuff(T)(const ref T val) {
>> // do stuff.
>> }
>>
>> T getVal() {
>> return someValue;
>> }
>>
>> void main() {
>> doStuff(getVal()); // Doesn't currently work.
>> }
>>
>> For non-const ref parameters, it's understandable that passing rvalues in
>> doesn't work because this is likely a bug that the compiler should catch.
>> However, for const ref parameters, can't the compiler just implicitly put the
>> value on the caller's stack frame and convert it to an lvalue rather than
>> forcing the programmer to write the boilerplate to do this manually? This
>> would result in:
>>
>> doStuff(getVal()); -->
>>
>> auto __temp = getVal();
>> doStuff(__temp);
>
> I agree it hurts a lot. I faced the same problem implementing RefCounted: you can't return RefCounted object from one function and pass it by reference to another one. Passing it by value is not a good option.
The compiler will optimize that case.
Andrei
|
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jason House | == Quote from Jason House (jason.james.house@gmail.com)'s article > If T is a class, I agree it should work. If T is a struct, you'll need a stronger argument. Maybe scope const ref T would make sense. IMHO, non- scope ref T for structs is already a questionable practice, and I don't mind the compiler making that scenario tougher for me. Since when does scope even have any meaning for structs? |
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Mon, 14 Dec 2009 22:15:06 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > Eldar Insafutdinov wrote: >> dsimcha Wrote: >> >>> I mentioned this deep in another thread, but I think it deserves its own >>> thread. Can we get something like: >>> >>> void doStuff(T)(const ref T val) { >>> // do stuff. >>> } >>> >>> T getVal() { >>> return someValue; >>> } >>> >>> void main() { >>> doStuff(getVal()); // Doesn't currently work. >>> } >>> >>> For non-const ref parameters, it's understandable that passing rvalues in >>> doesn't work because this is likely a bug that the compiler should catch. >>> However, for const ref parameters, can't the compiler just implicitly put the >>> value on the caller's stack frame and convert it to an lvalue rather than >>> forcing the programmer to write the boilerplate to do this manually? This >>> would result in: >>> >>> doStuff(getVal()); --> >>> >>> auto __temp = getVal(); >>> doStuff(__temp); >> My vote for it. > > Binding rvalues to const references was probably the single most hurtful design decisions for C++. I don't have time to explain now, but in short I think all of the problems that were addressed by rvalue references, and most of the aggravation within the design of rvalue references, are owed by that one particular conversion. > > If we ever allow automatic conversion of an rvalue to a ref, we should know very well what we're doing. > > > Andrei What about allowing binding rvalue to final ref const(T) (final would mean tail-const and wouldn't allow taking address of that variable)? Wouldn't that allow the feature while side-stepping all the issues? |
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Mon, 14 Dec 2009 23:38:34 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > Denis Koroskin wrote: >> On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha <dsimcha@yahoo.com> wrote: >> >>> I mentioned this deep in another thread, but I think it deserves its own >>> thread. Can we get something like: >>> >>> void doStuff(T)(const ref T val) { >>> // do stuff. >>> } >>> >>> T getVal() { >>> return someValue; >>> } >>> >>> void main() { >>> doStuff(getVal()); // Doesn't currently work. >>> } >>> >>> For non-const ref parameters, it's understandable that passing rvalues in >>> doesn't work because this is likely a bug that the compiler should catch. >>> However, for const ref parameters, can't the compiler just implicitly put the >>> value on the caller's stack frame and convert it to an lvalue rather than >>> forcing the programmer to write the boilerplate to do this manually? This >>> would result in: >>> >>> doStuff(getVal()); --> >>> >>> auto __temp = getVal(); >>> doStuff(__temp); >> I agree it hurts a lot. I faced the same problem implementing RefCounted: you can't return RefCounted object from one function and pass it by reference to another one. Passing it by value is not a good option. > > The compiler will optimize that case. > > Andrei How can it optimize away a function with a side effect (RefCounted ctor/dtor invokes an interlocked increment/decrement that theoretically may destroy an object, but wouldn't in practice)? Make it special for compiler? |
December 14, 2009 Re: const ref rvalues | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | Denis Koroskin wrote:
> On Mon, 14 Dec 2009 23:38:34 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Denis Koroskin wrote:
>>> On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha <dsimcha@yahoo.com> wrote:
>>>
>>>> I mentioned this deep in another thread, but I think it deserves its own
>>>> thread. Can we get something like:
>>>>
>>>> void doStuff(T)(const ref T val) {
>>>> // do stuff.
>>>> }
>>>>
>>>> T getVal() {
>>>> return someValue;
>>>> }
>>>>
>>>> void main() {
>>>> doStuff(getVal()); // Doesn't currently work.
>>>> }
>>>>
>>>> For non-const ref parameters, it's understandable that passing rvalues in
>>>> doesn't work because this is likely a bug that the compiler should catch.
>>>> However, for const ref parameters, can't the compiler just implicitly put the
>>>> value on the caller's stack frame and convert it to an lvalue rather than
>>>> forcing the programmer to write the boilerplate to do this manually? This
>>>> would result in:
>>>>
>>>> doStuff(getVal()); -->
>>>>
>>>> auto __temp = getVal();
>>>> doStuff(__temp);
>>> I agree it hurts a lot. I faced the same problem implementing RefCounted: you can't return RefCounted object from one function and pass it by reference to another one. Passing it by value is not a good option.
>>
>> The compiler will optimize that case.
>>
>> Andrei
>
> How can it optimize away a function with a side effect (RefCounted ctor/dtor invokes an interlocked increment/decrement that theoretically may destroy an object, but wouldn't in practice)? Make it special for compiler?
The compiler can optimize away all copies followed by the destruction of the source. It suffices to just move memory.
Andrei
|
Copyright © 1999-2021 by the D Language Foundation