trying to modify

Konsist
            .scopeFromProject()
            .functions()
            .assert { it.hasReturnType }

in a way that it will fail if a method return type is not specified but it can still pass in case the method is returning nothing so

fun test1() { /* something */ }

should pass while

fun test2() = 5

should fail because test2 should specify the return type as

Int

is there any idea how we can check this with Konsist ?

I also tried this but got the same limitations that you also get. If you are using detekt in your project, there is a rule that you can use for this: https://detekt.dev/docs/rules/libraries/#librarycodemustspecifyreturntype

Yeap I am aware of that one and actually i created that feature request 🙂 But it requires the library rule set, so I was asking in case I can get rid of it 🙂

Yes that's also my wish 😂

You can put everything after

=

character including lambdas and then tings become quite complex. We will not be able to make it perfect without adding

K2 Compiller

support (to be investigated). However we will be able to match detekt check and most likely make it a bit better as Konsist has context of entire code base, nit just a single file. Thats' being said I made a note and we already have a ticket to improve this behaviour. https://lemonappdev.atlassian.net/browse/KON-522 At the end of the day Konsist is parsing Kotlin code in form of text, so the idea is to give API for what you see in a "Kotlin text file" (and a bit of things that we can deduct). BTW You can consider using

hasBlockBody()

&

hasExpressionBody

methods to improve your check. The expression body in most cases means that function has the return type, however you can also write such code

fun test2() = println(5)

, so this will not be perfect. Thx for the feedback

I think the important thing you mentioned is

At the end of the day Konsist is parsing Kotlin code in form of text

. That is the difference between Konsist and detekt. Konsist can use everything that is available in the text representation of a Kotlin file but intepretation is something different.

Exactly: Code like the above one is easy to process, however there are many more complex scenarios e.g.:

fun test3() = { anything can happen here }

fun test4() = Foo()
                .doSomething()
                .also { }

Thank you for the comment Igor, the JIRA ticket that you share looking like going to solve the issue and i will definetelly have a look at below, it will still help partially for the most of the cases 🙂

BTW You can consider using

hasBlockBody()

&

hasExpressionBody

methods to improve your check.

I'm no expert on the detekt library but the rule that detects missing return types needs type resolution (https://detekt.dev/docs/gettingstarted/type-resolution) that enables advanced information of the source code.

I will take a look