Funny that you wrote `break if v == 11`. In a prototype I wrote 5 years ago (to learn syntax handling) I implemented this. What ended up happening is if I could do `break if ...` then I'd wanted to do expr if. Like `fn() if v == 1`. But at that point it gets confusing to read. Maybe I can try implementing this only for `break`, `continue` and `return` but it might annoy people because expressions aren't allowed. If expressions are then it's back to the problem I had in the prototype

I don't know if it'll make things more clear to you but curlys aren't nessicary when you use return/break/continue. I didn't write it because I didn't want to scare people off with the lack of curlys or confuse people on the front page

The `::` part looks nice. Would you want the statement to be forced on the same line? Or not like how C allows statements after `else`? As mentioned the compiler forces curly braces so it'll have to be forced to be on the same line as the on statement and I don't know if you'll find that to be a dealbreaker

Ruby has "expr if cond" and is very readable. I use it all the times if cond is short.

I like the _OnBreak _OnComplete _OnEmpty . I think they simplify some loops and make those found_something variables go away. However I don't like that they start with an underscore. It feels so old (C and Python, which was designed at the end of the 80s.)

Case conventions are a little strange, something is lower case (main, for), something is camel case, something are upper case (methods?)

= := .= could be a little confusing. Why not only one? The compiler should know what to do because of the mut, out keywords.

About style: { sometimes leads a line, sometimes doesn't.

> However I don't like that they start with an underscore

Early on _[A-Z] meant reserved variable so that's why it's currently _On. Many keywords are a single word and common enough that it shouldn't bother anyone that it's reserved. However I'm not great coming up with a style guide. On empty is two words, I have no idea how it should be written and everyone seems to have their own style.

Do you have a suggestion for the _On keywords?

> Why not only one? The compiler should know what to do because of the mut, out keywords

You noticed the out keyword? It's not recommended we only use that to interface with C code. Returning multiple variables is much better IMO (I won't speak for everyone). Accumulator and dynamic arrays are common enough that I didn't want to force people to write mut each time. It's simply `:=`

> Do you have a suggestion for the _On keywords?

Let's suppose that in the future you want to add an argument to the break keyword to signal why the loop returned early. I use a string (btw, does the language have symbols / atoms?)

  break "found" 
  break "eof" 
  break "invalid input" 

Then you could have

  on "found" 
  on "eof" 
  on "invalid input" 

with only one keyword. And

  on "complete" 
  on "empty" 

> Returning multiple variables is much better IMO

I agree but declaring a name for what you return is nice because it explains the purpose of the returned values. They could go outside the ()s.

  stat(file) out length, created, modified

I'm thinking more about your suggestion but off the top of my head I don't know why one would want a break reason. If one comes up anytime soon I'll 100% remember this post

> I agree but declaring a name for what you return is nice because it explains the purpose of the returned values. They could go outside the ()s.

So you're not suggesting an 'out' keyword your saying names on return values? I like the idea but in practice I'm not sure if any IDE would show you the names? I think many do show comments if you place them the line before so that could be an alternative solution

One reason I don't like out params is because it conflicts with the design of the language. The language prefers you to assign variables and people will want to modify their variables (or arrays and struct members) with the out param and having something be declare OR assign causes problems because its too easy to make a typo and not find it for many many minutes. Writing the type then using out goes against the flow of the language which is why I prefer returning multiple values.

But I don't know all the use cases and everyones preference so there very well be a good reason you'd want an out parameter

> If expressions are then it's back to the problem I had in the prototype

If it’s C like then the ExpressionStatement, umm…statement covers this; it’s how “if (foo=1) bar();” works (or leads to bugs depending on your point of view).

Also curious on how the automatic memory management works, might be on the website somewhere but I didn’t look past the first page.

> automatic memory management

I wrote some specifics in this thread over a few comments but that and the type system are complex. It can be a talk and writing short post probably will satisfy no one

> But at that point it gets confusing to read.

What's confusing about that? Perl has that, I use it all the time.

Comparing perl to a language that wants to be readable is very funny to me

For me, the problem is when my expression got long or if I call a function with multiple parameters. The more complex the line is the easier it is to not notice the `if`. Also I agree with what the other person said, it doesn't match the order if you read top down left to right

Ruby also has it and it is easily readable.

What I find confusing about it is that it does not match the execution order.

Perl is my main, and I never use that feature.

It’s way more clear and robust than a one liner if.

A for loop also doesn’t match what’s being executed. It’s s actually a do/while loop

One-liner if statements is another pattern I stay away from as much as possible...

I usually use it to do some pre conditional checks, or to return early

That's fair. I still use 3-liners for that.

De gustibus non est disputandum - I like the original version much better than your proposal.

I don't know why people are downvoting you for sharing your suggestions. Your syntax suggestion for _OnBreak and _OnComplete does seem better for the following reason - 1. Both are related to the for loop, and the usage of :: makes them stand out and seems to gives them more context. 2. Easier and elegant to read. (But is that because the example uses a 1 line code? What would be the best way to present multiline code without confusion?)

(I would have preferred if the _OnBreak and _OnComplete statements was inside the for loop as that removes any ambiguity that it is part of it and effects the for loop).

However, `if v == 11 {break}` is definitely more readable than `break if v == 11`. If you are using curly braces as part of your syntax, and for blocks of code, it's better to use it with consistence. That can be confusing with `break {if v == 11}` as it breaks the syntax grammar, when you consider what break does.

Maybe do some Ruby programming and then reconsider what you think is more readable.

the break, food out break out of the if block? Or somewhere else? It’s confusing

That's silly - this isn't Ruby. It's a new language still under development and thus will have its own syntax. Obviously any language will be unreadable if you don't understand its grammar (syntax). Readability is tied to the syntax of a programming language. (And Ruby is great example of this - I am used to Python and I found reading Ruby code to be very cumbersome because of its weird syntax, which I didn't bother to learn). This a C / C++ / D like language.