Speaking of Context parameters (and arrow), i ran ...

# compiler

[Michael Friend]

Speaking of Context parameters (and arrow), i ran into a bit of a weird unexpected interaction between lambdas with receivers and lambdas with context parameters when nested with each other i brought up in the arrow channel. Basically when i call a function that takes a lambda with a Raise<E> receiver, then within that lambda i call a function that takes a context(Raise<E>) ()->T , calling raise(...) within the inner lambda block has ambiguity on whether it should refer to Raise<E>.raise() on the outer receiver or context(_: Raise<E>) raise() on the inner context and the compiler seems to always choose the outer receiver over the inner context.
I would expect it to work like having nested lambda with receiver blocks where it makes the call on the nearest/innermost matching receiver and just include available context params in that search

[Alejandro Serrano.Mena]

unfortunately, by design a member function takes precedence over a top-level functions (with or without context parameters)... we're working on a solution for some of those cases in combination with DslMarker, though, but it's too early right now to tell if this will solve the entire problem or not

[Michael Friend]

Ahhh so it's not necessarily a context param vs receiver/member issue it's a receiver/member vs top level function issue. That makes a lot more sense at least. I did have the hope that DslMarker could help there once it works fully with context params

[Michael Friend]

This use case was solved by just using a lambda with receiver instead of with context param. Once context params are fully out i imagine this already kinda niche case of name collision becomes even less common since this issue only really came from providing both versions of the same function