also, is `context(InternalAddOp<T>, InternalAddOp<R>)` prohibited, cause in theory they ...

# language-evolution

[Kroppeb]

also, is context(InternalAddOp<T>, InternalAddOp<R>) prohibited, cause in theory they could have a subtype relation between them, or is that an error?

[Kroppeb]

T and R don't have any type bounds

[simon.vergauwen]

IRRC there was a discussion going on about this, that in this case you would need to explicitly name them. So that inside the function there is no confusion.

For satisfying the context regular scoping rules apply.

[simon.vergauwen]

I however cannot seem to find it anymore

[Kroppeb]

Well, I was planning on using it for advent of code, but it seems it's not yet really feasible to do so

[Kroppeb]

Rip my cursed idea for using traits

[simon.vergauwen]

Even if you do this?

context(t@InternalAddOp<T>, r@InternalAddOp<R>)

[Kroppeb]

gives the same error

[Kroppeb]

I realized today that my "short" version of todays solution had a scan that was calculating a cumulative sum, and I have a method for that, except that on only works on Ints

[Kroppeb]

So I thought I'd see if I could use contexts as traits to implement stuff like this over many types at the same time

[Youssef Shoaib [MOD]]

That error can be suppressed btw. @Suppress("SUBTYPING_BETWEEN_CONTEXT_RECEIVERS")

[Kroppeb]

seems like you can supress anything in kotlin