October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | http://ideone.com/KBf8k9 |
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Friday, 21 October 2016 at 14:22:27 UTC, Steven Schveighoffer wrote: > On 10/21/16 10:12 AM, Temtaime wrote: >> 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: >>>> [...] >>> >>> 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. >>> >>> [...] >> >> Please, no. >> It's fully clear that { stmts } createa a lambda, just () is ommited. > > No, it's not. > > { int x; x = 2; } > > Is not a lambda. It's a scope. > > So the meaning changes based on where it's used. I totally agree that we should remove that feature. > > -Steve {} in swift is a lambda too. I think swift has better lambda syntax. Maybe could help for a better syntax in d. reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in return s1 > s2 }) reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in return s1 > s2 } ) reversedNames = names.sorted(by: { s1, s2 in return s1 > s2 } ) reversedNames = names.sorted(by: { s1, s2 in s1 > s2 } ) reversedNames = names.sorted(by: { $0 > $1 } ) reversedNames = names.sorted(by: >) someFunctionThatTakesAClosure(closure: { // closure's body goes here }) someFunctionThatTakesAClosure() { // trailing closure's body goes here } let strings = numbers.map { (number) -> String in var number = number var output = "" repeat { output = digitNames[number % 10]! + output number /= 10 } while number > 0 return output } |
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 10/21/16 10:28 AM, Kagamin wrote:
> On Friday, 21 October 2016 at 14:16:26 UTC, Steven Schveighoffer wrote:
>> How about in general forbidding lambda statements that aren't called
>> or used anywhere?
>
> How?
>
> int main()
> {
> int a;
> auto b = ()=>{a++;};
> b();
> assert(a==1);
> return 0;
> }
This lambda is both used in an assignment, and called.
If I do this:
10;
It's flagged as not having any effect. Similarly if I do:
() => 5;
Then it's not used/called. What is the point?
-Steve
|
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | On 10/21/2016 09:42 AM, Adam D. Ruppe wrote:
> I think deprecating `{ lambda }` is really the way to go.
Another possibility is to disallow an ExpressionStatement that consists solely of a lambda. There is precedent for that, e.g. the statement "1 + 1;" is disallowed. -- Andrei
|
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 10/21/16 10:28 AM, Kagamin wrote:
> On Friday, 21 October 2016 at 14:16:26 UTC, Steven Schveighoffer wrote:
>> How about in general forbidding lambda statements that aren't called
>> or used anywhere?
>
> How?
>
> int main()
> {
> int a;
> auto b = ()=>{a++;};
> b();
> assert(a==1);
> return 0;
> }
Oh, I see. This error that I didn't see right away wouldn't be prevented, but that's not what I was talking about. I just meant that the original problem shouldn't have happened, since the lambda is never used.
I totally agree that the above sucks and should be fixed.
-Steve
|
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to mogu | On 10/21/16 10:38 AM, mogu wrote: > On Friday, 21 October 2016 at 14:22:27 UTC, Steven Schveighoffer wrote: >> On 10/21/16 10:12 AM, Temtaime wrote: >>> 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: >>>>> [...] >>>> >>>> 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. >>>> >>>> [...] >>> >>> Please, no. >>> It's fully clear that { stmts } createa a lambda, just () is ommited. >> >> No, it's not. >> >> { int x; x = 2; } >> >> Is not a lambda. It's a scope. >> >> So the meaning changes based on where it's used. I totally agree that >> we should remove that feature. >> > > {} in swift is a lambda too. Swift doesn't have arbitrary scopes. So there is no ambiguity. > I think swift has better lambda syntax. > Maybe could help for a better syntax in d. We likely are not going to change the lambda syntax. However, it's possible we could remove the ambiguous cases. > reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in > return s1 > s2 > }) > reversedNames = names.sorted(by: { (s1: String, s2: String) -> Bool in > return s1 > s2 } ) > reversedNames = names.sorted(by: { s1, s2 in return s1 > s2 } ) > reversedNames = names.sorted(by: { s1, s2 in s1 > s2 } ) (s1, s2) => s1 > s2 Seems pretty good to me > reversedNames = names.sorted(by: { $0 > $1 } ) With the original string lambdas, this was possible as "a > b". I'm not sure this case is worth much effort to add. > reversedNames = names.sorted(by: >) Not sure if we'll ever get this in D :) > > someFunctionThatTakesAClosure(closure: { > // closure's body goes here > }) > someFunctionThatTakesAClosure() { > // trailing closure's body goes here > } Yes, I've seen and used this. I think this is actually a little confusing. -Steve |
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | Allow new syntax makes codes simpler in some cases: writeln({ int a = 5; return a + 5; }()); => writeln{ int a = 5; return a + 5; }(); [1,2,3].fold!((a, b) => a + b).writeln; => [1,2,3].fold!{a, b => a + b}.writeln; |
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Friday, 21 October 2016 at 12:34:58 UTC, Andrei Alexandrescu wrote:
> What would be a good solution to forbid certain constructs in the increment part of a for statement?
For this specific case, a clear solution would be to forbid evaluating lambdas as a boolean expression, because they will always be true, and thus almost always an error. Same as with assignments in if statements. If intended, it can be worked around with "!is null".
|
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vladimir Panteleev | On 10/21/2016 12:39 PM, Vladimir Panteleev wrote:
> On Friday, 21 October 2016 at 12:34:58 UTC, Andrei Alexandrescu wrote:
>> What would be a good solution to forbid certain constructs in the
>> increment part of a for statement?
>
> For this specific case, a clear solution would be to forbid evaluating
> lambdas as a boolean expression, because they will always be true, and
> thus almost always an error.
Read the example again, the lambda is not evaluated as a bool. -- Andrei
|
October 21, 2016 Re: "for" statement issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Friday, 21 October 2016 at 16:46:08 UTC, Andrei Alexandrescu wrote:
> Read the example again, the lambda is not evaluated as a bool. -- Andrei
My bad.
In that case, what Steven said.
|
Copyright © 1999-2021 by the D Language Foundation