Hi all, is there a more decoupled guard solution planned for Kotlin? I see Elixir`s guard as a good example and it's a solution that I really would like to use, translated to Kotlin is something like:

fun handleError(e: Exception) if(e is NetworkException) {}

fun handleError(e: Exception) if(e is WrongUserException) {}

fun handleError(e: Exception) if(e is OtherException) {}

Hmm, I'm not really sure how it works in Elixir, looks as some sort pattern matching, wouldn't combine this to one function work for you:

fun handleError(e: Exception) {
  when (e) {
     is NetworkException -> ...
     is WrongUserException -> ...
     else -> ...
  }
}

actually this

when

is exactly what I want to avoid and my main problem today... Imagine a lot of Exception checkings, this code is getting to be a modifiable and not extensible one, splitting it with functions we can improve that, separating more the code, of course we can create other solutions to handle that like I've already did (composing exceptions handling, avoiding this

when

), but I really think this guard solution is the thing that I'm looking for to solve it

It can be some more pluggable solution, like a map of Exception to Function that handles exception, but it really depends on case. There is no pattern matching in Kotlin, so you still need some code that would map to particular exception handler

yeah sure we can map handlers, we can compose them do a lot of things about them but still have some kind o work to that, letting it to the compiler would be great in my opinion, but I really don't know the effects to Kotlin compiler a solution like that, as u said there's no pattern matching in Kotlin but I either don't know an alternative solution to that (I'm really newbie to compilers)

I don't think that there is alternative solution with existing language features, if you have some opinion how it may be implemented and work you can propose it to #language-proposals, but it's quite a big work to just discuss it. You also can report it to Kotlin issue tracker and collect some opinions

Yeah I agree, is something really big and require a lot of usecases and explanations about why we would like that, just asked to know if we're already thinking in something like that.

There is also opened issue on Kotlin issue tracker about support of multiple exceptions in catch block, maybe it can be considered in the same task, to do some semi/automatic mapping, just a rough idea

Yeah this one could be actually covered too with compiler generating a bytecode for something like:

fun handleError_someHashCodeToConditionOne(e: Exception) {
  if (e is NetworkException) {}
}

But how would full code look like, who would call this function

in this solution probably we will end with all

handleError

being called, is not a good idea, maybe move that

when

logic in your first example part to compiler would be better solution, something like (but of course I still don't know the effects of it to compiler or if it's possible todo that):

fun handleError_someHashCodeToConditionOne(e: Exception) {}

fun handleError_someHashCodeToConditionTwo(e: Exception) {}

fun main() {
// all stuffs here and now create checks to      //figure out which handleError we're going to //call and the expressions are geted from the //function declaration like
  if (e is NetworkException) handleError_someHashCodeToConditionOne(e)
  if (e is WrongUserException)
handleError_someHashCodeToConditionTwo(e)
}

Of course are missing a lot of usecases that I didn't think about it

My issue with this is how it will be scoped, how map exception to particular function? is it somehow integrated with try/catch? Or you just call

handleError(somError)

and it should automatically select proper function, if second than it looks as some generic pattern matching than something related to exceptions only and not sure how such haskell-style pattern matching would work with Kotlin, it’s dramatic change of how function resolution works

The idea is just call

handleError(somError)

and compiler decides based on function condition declarations which function will be called, the solution for that? I don't know, I see that with a giant change with pattern matching or an alternative solution as I said with some similiar solution to what compiler does with extension functions (get the written function and generate bytecode to other function struct based on the original)

So instead of writing a function with

when

like @gildor suggested you want to add some very special syntax to a language, so that compiler can generate this function for you? Does this worth it? Especially if this most probably will be limited that all these functions should be placed in the same file (like for sealed classes) as it may be hard to find all implementations otherwise.

And also not really useful, because you cannot handle more than one class by the same function, there is just no syntax to express it, otherwise it would require union types support

Actually I'm looking for a elegant and extensible solution for that, I've already thought in some things like: Mapping, Composing, Create a pre processor to handle that, but a language solution sounds more natural and pretty and I understand pattern matching is not something to solve this problem in specific but change completely the way to develop things in Kotlin, I'm not proposing anything here, just to know if someone thought about a solution for that in language level.

I think there is nothing more flexible and extenaible than explicit mathching using

with

but how to match it correctly when u have a "generic type", in some place we need to make a check to handle the correct type being an explicit checking or an implicit, but maybe the features of

when

implies us to use that in the end being easier to read and understand but being less extenaible.

What do you mean by explicit/implicit check? Both in your example and in suggested

when

there is an explicit check for an argument type. And why do you consider

when

to be less extensible?

What I mean by implicit is some solution like mapping handlers, that I think it's better. When you for example have a function that handle error cases by checking its type like:

fun handleError(e: Exception) {
  when(e) {
    is NetWorkProblem -> {}
    is OtherProblem -> {}
  }
}

and you need to put some other handling on this solution you're actually modifying your code instead of extending it, in some time you will figure out that you've created a giant solution just to check which type is your error, one another good example is consuming states from a state machine with

when

, I've created an alternative way to supply that but I'm still not 100% satisfied with that. ( https://github.com/bloderxd/result#error-cases-with-composition )

Do you know about arrow library? I didn’t use it but maybe you will find what you want there. For example, https://arrow-kt.io/docs/arrow/core/try/

Yeah, I've already saw it, it's a good library to functional development but in the end we have the same issue.

I'm really not sure how Result is helpful in this and how it make it more readable or extandable.

yeah sure, you can have type checking with sealed class but in the end we end up in the same case when we check which class is, but probably avoid it is something that is not considered by language and the community, thank you for your considerations about it.