Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
October 20, 2020 Any reason why ++1 is not folded to a new constant? | ||||
---|---|---|---|---|
| ||||
I've reached a similar problem in another language and I wanted to see what is the D policy. I've been surprised by the result. It seems that there's no special case for compile-time-only values, eg this case of RValue: --- void main() { writeln(++1); // NG: cannot modify constant `1` } --- is there any reasons why ++1 is not optimized to 2 ? Thanks for the enlightment. |
October 20, 2020 Re: Any reason why ++1 is not folded to a new constant? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Basile B. | On Tuesday, 20 October 2020 at 12:41:48 UTC, Basile B. wrote:
> I've reached a similar problem in another language and I wanted to see what is the D policy. I've been surprised by the result. It seems that there's no special case for compile-time-only values, eg this case of RValue:
> ---
> void main()
> {
> writeln(++1); // NG: cannot modify constant `1`
> }
> ---
>
> is there any reasons why ++1 is not optimized to 2 ?
>
> Thanks for the enlightment.
well my first guess is that it's because it's lowered to a binass operation before optimization.
when you think that the expression optimizer sees
`writeln(++1)`
actually it sees
`writeln(1 += 1)`
hence the error...
|
October 21, 2020 Re: Any reason why ++1 is not folded to a new constant? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Basile B. | On 10/20/2020 5:41 AM, Basile B. wrote:
> I've reached a similar problem in another language and I wanted to see what is the D policy. I've been surprised by the result. It seems that there's no special case for compile-time-only values, eg this case of RValue:
> ---
> void main()
> {
> writeln(++1); // NG: cannot modify constant `1`
> }
> ---
>
> is there any reasons why ++1 is not optimized to 2 ?
Because ++ is supposed to operate on an lvalue, and `1` is an rvalue. `++1` is nonsense.
I don't see the point to adding a special case for it - special cases are warts and need strong justifications to add.
|
October 22, 2020 Re: Any reason why ++1 is not folded to a new constant? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 21 October 2020 at 21:49:11 UTC, Walter Bright wrote:
> Because ++ is supposed to operate on an lvalue, and `1` is an rvalue. `++1` is nonsense.
>
> I don't see the point to adding a special case for it - special cases are warts and need strong justifications to add.
👍, well said.
I hope every D language feature has no special cases.
|
October 22, 2020 Re: Any reason why ++1 is not folded to a new constant? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 21 October 2020 at 21:49:11 UTC, Walter Bright wrote:
> On 10/20/2020 5:41 AM, Basile B. wrote:
>> I've reached a similar problem in another language and I wanted to see what is the D policy. I've been surprised by the result. It seems that there's no special case for compile-time-only values, eg this case of RValue:
>> ---
>> void main()
>> {
>> writeln(++1); // NG: cannot modify constant `1`
>> }
>> ---
>>
>> is there any reasons why ++1 is not optimized to 2 ?
>
> Because ++ is supposed to operate on an lvalue, and `1` is an rvalue. `++1` is nonsense.
>
> I don't see the point to adding a special case for it - special cases are warts and need strong justifications to add.
The question is then: why did it compile?
gcc gives
error: lvalue required as increment operand
when one tries it in C.
|
October 22, 2020 Re: Any reason why ++1 is not folded to a new constant? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Patrick Schluter | On Thursday, 22 October 2020 at 09:49:32 UTC, Patrick Schluter wrote: > > The question is then: why did it compile? > gcc gives > error: lvalue required as increment operand > > when one tries it in C. It doesn't ? https://run.dlang.io/is/sk4kKw |
Copyright © 1999-2021 by the D Language Foundation