# Break \ **URL:** \ **Category:** Language Design\ **Created:** [June 28, 2022, 11:02am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114 "2022-06-28T11:02:22Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![igr](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/igr/32/9396_2.png) [@igr](https://discuss.kotlinlang.org/u/igr)\ **Post date:** [June 28, 2022, 11:02am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/1 "2022-06-28T11:02:22Z")
I show an interesting syntax sugar in Crystal Lang ([https://crystal-lang.org](https://crystal-lang.org)) - which is, btw, an interesting one to look upon, as it is quite concise and clear language. Anyway, what about adding the following: ```auto break if (a > 0) ``` It is just for the clarity, instead of ```nohighlight if (a>0) break ``` In order words: `break ` Why do I find it better? Because the `break` is more visible. In the body loop, it becomes a bit more clear where the `break` is. I was working with some crystal code, and it really made a difference. ---
**Author:** ![broot](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@broot](https://discuss.kotlinlang.org/u/broot)\ **Post date:** [June 28, 2022, 12:42pm UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/2 "2022-06-28T12:42:32Z")
Idea is interesting, especially because I personally highly prefer writing code that puts things like `return` or variable assign to the beginning of a code flow, e.g.: ```kotlin return if (cond) { ... } else { ... } ``` Instead of: ```kotlin if (cond) { ... return ... } else { ... return ... } ``` The first code sample is much clearer to me. Still, I think this suggested syntax is a very “heavy” addition. It is not some small improvement, it changes the whole concept of how to read the code. It is more like a revolution than evolution. Right now, if a line of code starts with a statement / operation, then this operation is always (?) unconditional. If a line starts with `a =` then there is no way it won’t assign `a` (I ignore exceptions). Also, all special keywords and statements generally affect what is on their right side, not left side. The code is generally read from the left to the right. Your suggested change is inconsistent with pretty much everything that already exist in Kotlin. Or maybe I’m missing some similar constructs? ---
**Author:** ![gidds](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/gidds/32/10865_2.png) [@gidds](https://discuss.kotlinlang.org/u/gidds)\ **Post date:** [June 28, 2022, 4:35pm UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/3 "2022-06-28T16:35:32Z")
Something similar Perl does. It hard to read but I find. Demonstrates the problem I hope this! Specifically, I find it far too easy to miss conditionals when they’re tucked away at the ends of lines. Kotlin code can be scanned very quickly to get the rough idea of what’s going on, because the structural stuff is generally at the starts of lines — so even without reading the rest, you get a feel for how the code is structured and which bits you need to look more closely at. (@broot, in your example, I notice you prefer the version which adheres to that.) Conditional suffixes break\* that. In OP’s example, _both_ parts are structural — but I’d never put them both on the same line, for precisely that reason. I always put the body of an `if` statement on a new line: ``` if (a > 0) break ``` I find that easier to read anyway, but it’s particularly important in cases like this. (I’m happy to put `if` _expressions_ all one line — but only if they’re not too long, and don’t include structural keywords such as `return`.) (This change would also give two different ways to write exactly the same thing — a step down the road that leads to everyone using their own, separate dialect and it being much harder to share code…) As broot says, this would be a pretty drastic change to how code can be structured and read, and I’d want to see a much stronger justification for it. * * * (\* Pun intended.) ---
**Author:** ![igr](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/igr/32/9396_2.png) [@igr](https://discuss.kotlinlang.org/u/igr)\ **Post date:** [June 29, 2022, 9:32am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/4 "2022-06-29T09:32:37Z")
I don’t see the change as that drastic. And it is _optional_, regular `break` should still exist, no one is questioning that. I am just sharing my experience with Crystal. To be honest, I didn’t expect to like it; however, at the end I just found that I was appreciating this code more: ```auto break ifFooBar() ``` then this: ```auto if (fooBar()) break ``` break is more like applying the `map()` on the break container having the `true` as a default: `Break(true).map{ Unit -> boolean }` Right? 🙂 ---
**Author:** ![igr](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/igr/32/9396_2.png) [@igr](https://discuss.kotlinlang.org/u/igr)\ **Post date:** [June 29, 2022, 9:47am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/5 "2022-06-29T09:47:29Z")
> [@gidds](#): > > (This change would also give two different ways to write exactly the same thing — a step down the road that leads to everyone using their own, separate dialect and it being much harder to share code…) That is always the case with general-purpose languages. One may say the same for e.g. collections and sequences (I know, they are not different, but often I just want to damn iterate and not think about the differences). Or for the elvis operator - it does pretty much the same as if-else. For loop is a specification of the while loop, which is all the same, right? And yet, we should lean towards `generateSequence` (such a long name!) instead of using any loop at all 🙂 Look also for the operator `invoke()` - even I sometimes use `invoke()` explicitly: `Foo().invoke()` instead of `Foo()()`. TLDR: syntax sugar is exactly that - a different way of doing the same; but in a more _understandable_ manner. In this case, everyone will understand the difference; and _the readability_ of the code (one of the most important traits) will remain at least the same. Again, I am sharing my experience with Crystal. I am not favoring it over Kotlin, nope; and I didn’t even know it exist until last week, but I would it was very readable. The break syntax actually helped. When I do scan the unknown code, I want to first grasp the major flow, hence all IFs Breaks etc are getting in the way. That being said, I appreciated reading `break ` and simply skipping that part while scanning code. In the opposite case, reading `if (a)` would require mental processing, just to go to the next line that says `break`. Anyhow, just a simple idea. ---
**Author:** ![broot](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@broot](https://discuss.kotlinlang.org/u/broot)\ **Post date:** [June 29, 2022, 10:18am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/6 "2022-06-29T10:18:44Z")
> [@igr](#): > > break is more like applying the `map()` on the break container having the `true` as a default: > > `Break(true).map{ Unit -> boolean }` Sorry, I’m confused with this part. `break` is for control flow, it is similar to `return`, but I don’t see how it is similar to invoking a function. ---
**Author:** ![igr](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/igr/32/9396_2.png) [@igr](https://discuss.kotlinlang.org/u/igr)\ **Post date:** [June 29, 2022, 11:15am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/7 "2022-06-29T11:15:28Z")
That example is written in the following manner: `break` is essentially a container of a boolean value that indicates that some flow has to break. As being a container, it may be a `Functor` with a `map()`. All control-related keywords could be containers, probably. Another angle: look at the `yield(value)`. It emits value in its scope. The same is: `break(value)`. It emits a boolean for the scope of the loop. `yield` should be a keyword, too (or break could be a method). Actually, if you think, `break` is `yield(true)`🙂 Another angle : `if` could always be added _after_ expression. Instead of saying `if (foo) a = 7` you could say `a = 7 if (foo)`. This maps logically to following: `container(lambda).invokeIf(expression)`. It’s the other way around. I know, I know, this is not how we used to think; but look, we are all learned to think that algorithms blocks are the (only) right way of constructing code from the very first days of our dev lives (a topic out of scope of this article). But would it be readable? Dunno. At least it would force having smaller `if` expressions, and that is a good thing (huge if blocks are really a pain). Please don’t get me wrong, just trying to give perspective here 🙂 That is why I am trying different languages all the time, and trying to figure out what might work. Have to go back to work, sorry; unfortunately, my daily tasks are not interesting as this discussion. ---
**Author:** ![broot](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@broot](https://discuss.kotlinlang.org/u/broot)\ **Post date:** [June 29, 2022, 11:40am UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/8 "2022-06-29T11:40:26Z")
> [@igr](#): > > Another angle : `if` could always be added _after_ expression. Instead of saying `if (foo) a = 7` you could say `a = 7 if (foo)`. Yes, this is actually my point. I don’t see a reason why we should have `break if (cond)` and not `return if (cond)`, `foo = 5 if (cond)`, `doSomething() if (cond)` or maybe even `for (item in items) if (cond) {}`. So we duplicate the whole syntax of the language, make the language more complicated and ambiguous only to allow developers to choose according to their personal taste. Then while reading the code we always have to look for both syntax options. For me this is like writing a book in both left-to-right and right-to-left, switching between them with each line. I appreciate people experiment with different ideas when designing a programming language, especially if this language is new and have a specific purpose. But that doesn’t mean we should pick existing language and add random features that are inconsistent with its whole design. In programming languages less is often more. ---
**Author:** ![broot](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@broot](https://discuss.kotlinlang.org/u/broot)\ **Post date:** [June 29, 2022, 12:27pm UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/9 "2022-06-29T12:27:29Z")
And about `yield` - this is a digression to the whole “conditional code” topic, but no, I don’t think `yield` has anything to do with `break`. Technically speaking, yes, all suspend functions in Kotlin could jump out of the current execution context. But this is a workaround that Kotlin team had to implement to allow running coroutines in the environment that doesn’t support them. Conceptually, `yield` just provides an item to the consumer and optionally waits for it. It doesn’t go anywhere. In Kotlin there are very few ways to “jump out” or break from the code context: `return`, `break`, `continue`, `throw`. And only `throw` is propagating, for the first three you have to use the statement directly in your code. This is to make the language more expressive, explicit. Same for functors. Kotlin is not a functional language. It has many elements of functional languages, but it isn’t one of them. Therefore, the control flow is very explicit. ---
**Author:** ![igr](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/igr/32/9396_2.png) [@igr](https://discuss.kotlinlang.org/u/igr)\ **Post date:** [June 29, 2022, 12:47pm UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/10 "2022-06-29T12:47:09Z")
> [@broot](#): > > But that doesn’t mean we should pick existing language and add random features that are inconsistent with its whole design. In programming languages less is often more. Sure, agree with that. Again, I am just expressing my findings. I was surprised as well, but there was a bit more clarity (for me), which I understand where it comes from. I do understand the point to keep things as it is ---
**Author:** ![igr](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/igr/32/9396_2.png) [@igr](https://discuss.kotlinlang.org/u/igr)\ **Post date:** [June 29, 2022, 12:48pm UTC](https://discuss.kotlinlang.org/t/break-boolean-expr/25114/11 "2022-06-29T12:48:00Z")
> [@broot](#): > > I don’t think `yield` has anything to do with `break`. just a note - both communicate with the scope they are executed in. yield provides values, break breaks the scope flow.