Fat arrow =>

[Helgef]

I'd say it would be nice, but your particular example can be acheived with ?:. And as said by lexikos, the benefits diminishes when the function becomes longer. In particular, I think mulitline function definitions in a function call becomes quite ugly with only a few lines of code, and especially if it is not in the last parameter, or if done in mulitple parameters. Further, when naming a function, it is much more sensical to me, to do so separate from a function call. So you might aswell use a nested function for more elaborate code. Eg,

Code: Select all

myFunc(){
	gui := guicreate()
	Gui.OnEvent( "Close",  "closeApplication")
	closeApplication(){	 ; Adding '=>' here adds no convenience
		if ( msgbox( "Do you really want to exit?") = "Yes" ) ;imagine the button options as Yes/No
			ExitApp()
	}
	gui.show("w200 h200")
}

cheers.

[lexikos]

Regarding () => { statements }, I do not think it would add a whole lot unless you could do same line statements, eg, while(x) y() or while(x) { ... }.

To be clear, I wrote it without line breaks so that it would appear as part of the sentence, but the actual code would have line breaks. It would be a standard block of code. I guess you thought otherwise, since I can't imagine why else same-line statements would matter.

Either only permit braces on multiline definitions or always demand, i.e, () => { {} }, the latter is less desirable imo.

That won't work. Object literals are allowed to contain hard line breaks. What is () => { {} } supposed to be? A block containing an empty block? If the point is to interpret anything that starts with { and isn't a valid expression as a block... no. That would be complicated to implement and hard for users to tell one from the other. Something like this could be interpreted both ways:

Code: Select all

x.OnEvent(y, () => {
    begin:
    MsgBox("flop")
})

{{ ... }} wouldn't be ambiguous, but why go that far? There's really no reason to use => with a block in the first place when () {} is both unambiguous and more familiar (especially if the function is named). => can exclusively mean a function which returns the following expression.

Actually, C# also uses => for expression-bodied members.

[nnnik]

I'd say it would be nice, but your particular example can be acheived with ?:.

Thats ugly.


[/code]
cheers.[/quote]

Further, when naming a function, it is much more sensical to me, to do so separate from a function call. So you might aswell use a nested function for more elaborate code. Eg,
;Adding '=>' here adds no convenience

Yes it adds convenience - it decreases redundance.

Actually, C# also uses => for expression-bodied members.

Quite a few languages support this expression.
C# also allows for statements though.
https://docs.microsoft.com/en-us/dotnet ... nt-lambdas

Heres a list of all languages that do according to Wikipedia:
https://en.wikipedia.org/wiki/Anonymous ... _languages

[Helgef]

To be clear, I wrote it without line breaks so that it would appear as part of the sentence, but the actual code would have line breaks. It would be a standard block of code. I guess you thought otherwise, since I can't imagine why else same-line statements would matter.

It was clear, I mean that allowing a multiline function body after => wouldn't add much unless a regular function body had good support for same line statements, hence you could still do your fat arrow with statements on one line, or at least few. More elaborate code might as well be (nested) functions (an existing feature, hence the wouldn't add much part).

What is () => { {} } supposed to be?

It should be () => { return {} }, meaning I made a (logical) mistake, not that it should be interpreted as such by the program.

Object literals are allowed to contain hard line breaks

I over looked that. When expr is an object literal, it would have to be enclosed in (), then (...) => expr with implied return and (...) => {statements} would work.

Yes it adds convenience - it decreases redundance.

Some in your original example (disregarding that you named it), the contrary in my modification of it. I think fat arrow followed by a block of code makes most sense when making unnamed functions outside of all functions. Inside a function or method, a nested function is fine. But sure, I imagine your example looks better than doing it with ?:.

Cheers.

[lexikos]

v2.0-a092 fixes the errors Helgef reported.

[lexikos]

I'll address the issues with static initializers in another post.

Static initializers and auto-execution