Jump to page: 1 2 3
Thread overview
Breaking ";" rule with lambda functions
Aug 01
pascal111
Aug 01
ag0aep6g
Aug 01
pascal111
Aug 01
ag0aep6g
Aug 01
pascal111
Aug 01
ag0aep6g
Aug 01
pascal111
Aug 01
ag0aep6g
Aug 01
pascal111
Aug 01
ag0aep6g
Aug 01
pascal111
Aug 01
pascal111
Aug 01
pascal111
Aug 01
frame
Aug 01
pascal111
Aug 02
pascal111
Aug 09
pascal111
August 01

We all know the strange syntax of lambda function within filter algorithm like "auto r = chain(a, b).filter!(a => a > 0);". My note is, don't we break D rules by leaving ";" after lambda function syntax?!

Many of D rules are taken from C, we know that, so a general basic rule is to put ";" after each statement, so the previous statement of filter should be "auto r = chain(a, b).filter!(a => a > 0;);"? Why D leaves ";" in this case?

August 01

On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

>

Many of D rules are taken from C, we know that, so a general basic rule is to put ";" after each statement, so the previous statement of filter should be "auto r = chain(a, b).filter!(a => a > 0;);"? Why D leaves ";" in this case?

a => a > 0 is not a statement. It's an expression.

August 01

On Monday, 1 August 2022 at 14:34:45 UTC, ag0aep6g wrote:

>

On Monday, 1 August 2022 at 14:15:31 UTC, pascal111 wrote:

>

Many of D rules are taken from C, we know that, so a general basic rule is to put ";" after each statement, so the previous statement of filter should be "auto r = chain(a, b).filter!(a => a > 0;);"? Why D leaves ";" in this case?

a => a > 0 is not a statement. It's an expression.

But it is still a "function", and functions make statements!! It's not a normal expression.

August 01

On Monday, 1 August 2022 at 14:39:17 UTC, pascal111 wrote:

>

On Monday, 1 August 2022 at 14:34:45 UTC, ag0aep6g wrote:
[...]

>

a => a > 0 is not a statement. It's an expression.

But it is still a "function", and functions make statements!! It's not a normal expression.

It's a normal expression.

foo => bar is an expression that doesn't involve any statement. So there's no semicolon.

(foo) { return bar; } does contain a return statement. As you expect, there's a semicolon. But it's still an expression like any other.

August 01

On Monday, 1 August 2022 at 14:46:33 UTC, ag0aep6g wrote:

>

On Monday, 1 August 2022 at 14:39:17 UTC, pascal111 wrote:

>

On Monday, 1 August 2022 at 14:34:45 UTC, ag0aep6g wrote:
[...]

>

a => a > 0 is not a statement. It's an expression.

But it is still a "function", and functions make statements!! It's not a normal expression.

It's a normal expression.

foo => bar is an expression that doesn't involve any statement. So there's no semicolon.

(foo) { return bar; } does contain a return statement. As you expect, there's a semicolon. But it's still an expression like any other.

If foo => bar == (foo) { return bar; }, then foo => bar is a function. "=>" is not an operator, it's a special symbol for lambda "function".

If A == B, so A's types is the same of B's type. How can it be withstanding foo => bar == foo => bar == (foo) { return bar; } and foo => bar is an expression and the other is a function?!! no sense.

August 01

On Monday, 1 August 2022 at 14:52:03 UTC, pascal111 wrote:

>

If foo => bar == (foo) { return bar; }, then foo => bar is a function. "=>" is not an operator, it's a special symbol for lambda "function".

If A == B, so A's types is the same of B's type. How can it be withstanding foo => bar == foo => bar == (foo) { return bar; } and foo => bar is an expression and the other is a function?!! no sense.

foo => bar and (foo) { return bar; } are both function literals, and they're both expressions. The concepts are not mutually exclusive.

August 01

On Monday, 1 August 2022 at 15:08:04 UTC, ag0aep6g wrote:

>

On Monday, 1 August 2022 at 14:52:03 UTC, pascal111 wrote:

>

If foo => bar == (foo) { return bar; }, then foo => bar is a function. "=>" is not an operator, it's a special symbol for lambda "function".

If A == B, so A's types is the same of B's type. How can it be withstanding foo => bar == foo => bar == (foo) { return bar; } and foo => bar is an expression and the other is a function?!! no sense.

foo => bar and (foo) { return bar; } are both function literals, and they're both expressions. The concepts are not mutually exclusive.

Surely, because it seems that you are real man, your word must be taken. Isn't (foo) { return bar; } an anonymous function or am I a wrong?!! It IS a function, not an expression.

August 01

On Monday, 1 August 2022 at 15:31:51 UTC, pascal111 wrote:

>

Surely, because it seems that you are real man, your word must be taken. Isn't (foo) { return bar; } an anonymous function or am I a wrong?!! It IS a function, not an expression.

It's both an anonymous function and an expression. I don't know why you think it can't be both.

August 01

On Monday, 1 August 2022 at 15:39:06 UTC, ag0aep6g wrote:

>

On Monday, 1 August 2022 at 15:31:51 UTC, pascal111 wrote:

>

Surely, because it seems that you are real man, your word must be taken. Isn't (foo) { return bar; } an anonymous function or am I a wrong?!! It IS a function, not an expression.

It's both an anonymous function and an expression. I don't know why you think it can't be both.

Nice that you still prove it to me. I thought something will happen to me in my life or area as a punishment from GOD who is watching everything because my insisting they are functions.

You didn't say before that they are both functions!!

But how can we accept that both are functions and expressions at the same time and we know that expressions can be used to build functions themselves?!! I think they are not the same.

August 01

On Monday, 1 August 2022 at 15:52:34 UTC, pascal111 wrote:

>

But how can we accept that both are functions and expressions at the same time and we know that expressions can be used to build functions themselves?!! I think they are not the same.

This is getting ridiculous. I'm out.

« First   ‹ Prev
1 2 3