I agree with you that it's 'Best Practices' solution rather than a 'Clever' one. However, there is no need to call names.

Yes, you are right. I fixed that now. Thanks for the help.

I don't really understand how the forking works here on codewars. But I think I did it right this time. Can you check?

Aah, I see. I fixed it now

What do you mean? I don't see anything abnormal.

I didn't realize the numbers were always an Int. So I made my solution based on the general Number type

Thanks

Improvement for the discription:

One day you had the terrible idea to go outside and hike a mountain. Unfortunately, you stumbled upon a giant bear and now you need to escape FAST.

You are deep in the forest and you have no idea where the exit is. Thankfully the trail is not cyclic and each path splits into only 2 directions (left and right). Some paths might be blocked by rocks or fallen trees. Then you cannot go in that direction. If both paths are blocked, then you're trapped in a dead end where the bear can catch you.

The mountain trail is modelled as following:

class Trail(val type: String, var left: Trail?, var right: Trail?)

The Trail can either be a "crossroad" or an "exit". A crossroad is basically a intersection that has 2 paths, left and right. (note that these paths can be blocked, this is denoted by a null). An exit is the goal to escape the bear. There is always an exit, but THERE IS ONLY ONE EXIT.

Thankfully you bought your drone with you to scout for the exit. Your drone can do a scan of the area but it is up to you to find an escape route to the exit given a provided trail:

fun findEscapeRoute(trail: Trail) : String

Your output should be directions in terms of "l" and "r" concatenated together to form a path to the exit. There is exactly one correct path for each trail.

For example, if I were to give you a trail like this:

└── crossroad
├── crossroad
| ├── NULL
| └── crossroad
| ├── exit
| | ├── NULL
| | └── NULL
| └── NULL
└── crossroad
├── NULL
└── NULL
then your solution should be

lrl

since you go left at the first crossroad, then right on the second crossroad, and left to reach the exit.

I had wanted to do the nested destructing as well, unfortunatly kotlin does not support this.

"package solution" needs to be added to the provided code

I think there might be some issue with the Kotlin random tests.

meet = {tim=3, jim=9, randy=0, sandy=7, andy=6, katie=4, laura=9, saajid=6, alex=0, john=9, mr=3}, boss = "andy"

Expected <Get Out Now!>, actual <Nice Work Champ!>.

However, doing the math manually, it should be "Nice Work Champ!"

Thanks for the replies. I think I get it now. When reaching the end of a function (a labeled block of code) without encountering a return statement, you continue executing the next lines (possibly a next function).

Yes, that is exactly what I thought.

But then lets follow the flow of the program:
First some initialisation, then proc_func is called for the first time. d != 1 so the ret command is skipped. proc_func is called for a second time. This skipping of ret and calling of proc_func will keep going until d == 1. Then the ret command returns from the last call of proc_func. But then there is no statement anynore, so the program terminates.

The expected behaviour of the program could be accomplished by adding a ret command after call proc_func.

@hobovsky I was working with Java8

@FArekkusu After returning to call proc_func (line 14) there are no more lines to keep moving forward to. Or do you keep moving forward into other functions?

@Blind4Basics If that is the case doesn't the test case above continue in an infinite loop?