October 22, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to mogu | On Friday, 21 October 2016 at 15:26:12 UTC, mogu wrote:
> [1,2,3].fold!((a, b) => a + b).writeln;
>
> =>
>
> [1,2,3].fold!{a, b => a + b}.writeln;
Probably (a, b => a + b) could be legal. Reasoning:
1. a could be an existing symbol in scope, otherwise it's an undefined identifier error.
2. If a was interpreted as an existing symbol which is followed by the comma operator, the expression (a) wouldn't have side effects so should be a compile error.
3. The bracketed comma expression would have to return the lambda b=>a+b as a value expression, which cannot compile because there are no arguments supplied for calling the lambda to obtain a value.
So this syntax seems available as it isn't currently used for working code. A small change, maybe, but it's good to reduce bracket nesting to help with reading complex nested expressions.
Destroy.
|
October 22, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On Friday, 21 October 2016 at 13:42:49 UTC, Adam D. Ruppe wrote:
> On Friday, 21 October 2016 at 13:33:26 UTC, Stefan Koch wrote:
>> It does create a lambda?
>> Hmm that should not happen.
>
> Eh, that's exactly what the language rules say should happen, and it actually does make sense to me... you might even want to use an immediately-called lambda to group several statements together into one expression.
>
int j;
for({j=2; int d = 3; } j+d<7; {j++; d++;}) {
}
I'm more surprised by the fact that `d` is declared inside the first curly braces, but is evidently still in scope outside of it...
|
October 22, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | On 10/22/2016 05:53 PM, Nick Treleaven wrote: > Probably (a, b => a + b) could be legal. Reasoning: > > 1. a could be an existing symbol in scope, otherwise it's an undefined > identifier error. > 2. If a was interpreted as an existing symbol which is followed by the > comma operator, the expression (a) wouldn't have side effects so should > be a compile error. How is it guaranteed that `a` doesn't have side effects? May be a function call, since empty parentheses can be omitted in calls. > 3. The bracketed comma expression would have to return the lambda b=>a+b > as a value expression, which cannot compile because there are no > arguments supplied for calling the lambda to obtain a value. The lambda itself is a value, no? ---- int a() { import std.stdio; writeln("a"); return 1; } void main() { int delegate(int) dg = (a, b => a + b); } ---- |
October 22, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | On 22.10.2016 17:53, Nick Treleaven wrote:
>>
>> [1,2,3].fold!{a, b => a + b}.writeln;
>
> Probably (a, b => a + b) could be legal.
It is. (It means pass a and the lambda b => a + b.)
|
October 23, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to ag0aep6g | On Saturday, 22 October 2016 at 17:11:26 UTC, ag0aep6g wrote: > How is it guaranteed that `a` doesn't have side effects? May be a function call, since empty parentheses can be omitted in calls. I missed that case. (Insert grumble about non-UFCS parenthesis omission being allowed). > The lambda itself is a value, no? > > ---- > int a() { import std.stdio; writeln("a"); return 1; } > > void main() > { > int delegate(int) dg = (a, b => a + b); > } OK. Though AIUI from 2.072 a() must return void for the comma expression to compile (then a+b wouldn't compile either). |
Copyright © 1999-2021 by the D Language Foundation