am I the only one thinks that context receivers is not a good idea (makes the code harder to follow)...

# random

[oshai]

am I the only one thinks that context receivers is not a good idea (makes the code harder to follow) ? Is there anywhere to vote against it?

[rtsketo]

It might indeed make a part of the code ambiguous to read, but regarding this, it's no different than using a single receiver. As with all things, it's something you can use wrongly or correctly. It's optional also, you don't have to use it at all.

[Rob Elliot]

It's optional also, you don't have to use it at all.

99% of the code I work with was not written by me.

[rtsketo]

How you want your codebase to be is something that needs to be discussed with your colleagues. IMHO, voting for removing a feature from the language isn't the right way to express your opinion regarding the code you work with.

[Rob Elliot]

90% of the code I work with was not written by my team or my colleagues.

[rtsketo]

@oshai regarding where you can vote against it. Well, I don't think you can vote, but you can express your opinion here.

[Rob Elliot]

Sorry, being a bit of an arse, but I genuinely think the "you don't have to use it" is a very poor argument in favour of a language feature.

Code is primarily a communication mechanism. I use open source libraries extensively; I read their code to understand what they do, to contribute and fix bugs, and to learn.

In my work I roll on and off teams; I inherit codebases over which I had no influence; I have to integrate with libraries where there's little other option.

I can't avoid confusing language features just by not using them whether individually or as a team.

In Groovy I not infrequently encountered DSL code that I found extremely difficult to decipher and to understand what it was doing (some of the dynamic builders...). In Scala some of the shapeless type magic I can only cargo cult, I can't understand why it works.

One of my favourite aspects of Kotlin is that I very rarely find Kotlin code I cannot comprehend.

(I'm not necessarily particularly anti this specific feature, I haven't really tried it yet, but I am wary of it... I use extension functions extensively, and sometimes get confused about the receiver, when there's only one.)

[christophsturm]

I thought its mostly for libraries and dsls and its discouraged to use it in application code, but I’m not sure where I read that.

[Rob Elliot]

One of the things I most disliked about Scala was the differentiation between code for libraries, dsls & application code, with this hierarchy where you were allowed to write stuff mere mortals couldn't understand in the libraries... I want to be able to read, understand & debug all the code running in my application, including the code in the libraries and dsls.

[christophsturm]

good point! I spend a lot of time reading and stepping through library code

[oshai]

my main concern is that libraries will use it and require me to provide the "context"

[oshai]

here is a discussion about it in rust: https://internals.rust-lang.org/t/implicit-parameters/14514

[therealbluepandabear]

I agree, it seems to just overcomplicate things. Can't really think of a scenario where I'd actually use it.

[Erick Sumargo]

Imo it can give benefit to set more scope constraints to a callable function (thx the multiple receivers), especially the top-level one.

With ext function alone, we can only scope a fun to a single receiver. Well, just cmiw.

[oshai]

I don't think it's the simplest solution to the multiple receivers problem.