Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optional end for single-expression, one-line block bodies #1657

Closed
StefanKarpinski opened this issue Dec 2, 2012 · 10 comments
Closed

optional end for single-expression, one-line block bodies #1657

StefanKarpinski opened this issue Dec 2, 2012 · 10 comments
Labels
speculative Whether the change will be implemented is speculative won't change Indicates that work won't continue on an issue or pull request

Comments

@StefanKarpinski
Copy link
Member

E.g., allow these:

for i=1:10 println(i)

if condition() println("met")
else println("not met")

while x < n f(x*=2)

try ignore_me_if_i_fail()

Since we would still allow end on single-expression, one-line block bodies, this wouldn't break any code, but I think it really makes a lot of things like this look better. Compare to how the above have to be written now:

for i=1:10 println(i) end

if condition() println("met")
else println("not met")
end

while x < n f(x*=2) end

try ignore_me_if_i_fail() end
@johnmyleswhite
Copy link
Member

Personally, I don't really like the single line if's, but would be up for some Ruby style

f(1.0) if true

@StefanKarpinski
Copy link
Member Author

I was gung-ho for that a long time ago, but my ardor has cooled somewhat. A lot of people seem to find that very hard to read.

@pao
Copy link
Member

pao commented Dec 2, 2012

I can't say I care for this. At least with the reversed-order Perl/Ruby style, you know that if you flip it you need to group the statements. This sounds as prone to error as the optional curlies around single-statement ifs in C.

@StefanKarpinski
Copy link
Member Author

I'm not sure where the errors might come from. How do you mean? It's interesting to get feedback on this idea, which has kind of been bouncing around my brain for a while.

@johnmyleswhite
Copy link
Member

I'm not sure about errors, but I find the optional curlies in C very confusing.

@StefanKarpinski
Copy link
Member Author

I don't find the optional curlies confusing, but it did once screw me over badly in 1998. I've managed to remain unaffected by them since then.

@JeffBezanson
Copy link
Member

Wow, that must have been a traumatic incident :)

@StefanKarpinski
Copy link
Member Author

Worst bug hunt I've ever experienced. It took me a week to track down a single stray semicolon.

@pao
Copy link
Member

pao commented Dec 3, 2012

Errors in editing, particularly editing code you're not familiar with. https://www.google.com/search?q="optional+curly+braces"+problem gives a few links, and I know I've run into this in C myself. It just seems like a hair too much rope just to make short lines even shorter.

If you wanted that, you should have gone with layout instead of begin..end.

Also: pesky semicolon. Been there, done that too.

@goszlanyi
Copy link

In Fortran only simple ifs without else clauses can be written on a single line without endif

if condition  do_something_useful
if condition  continue
if condition  break

are very useful and readable in my practice.
Could be useful here too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
speculative Whether the change will be implemented is speculative won't change Indicates that work won't continue on an issue or pull request
Projects
None yet
Development

No branches or pull requests

5 participants