Weird proposal: operator invoke extension on context
See original GitHub issueOk. This is a weird, but let me shoot it here. How about instead of writing:
withContext(UI) {
updateSomethingInMyUI()
}
we could just write:
UI {
updateSomethingInMyUI()
}
Does it make sense? 👍or 👎
Issue Analytics
- State:
- Created 5 years ago
- Reactions:12
- Comments:20 (12 by maintainers)
Top Results From Across the Web
multiple receivers on extension functions/properties : KT-10468
The proposal is to introduce the syntax for defining context-dependent declarations with special context receivers. Simply put, it is a kind of natural ......
Read more >Where is the proposal for standardization of "extension ...
There is a proposal for Unified (var Uniform) Call Syntax for C++. From 10,000 feet PoV, it will allow extensions methods a la...
Read more >Reactor 3 Reference Guide
We have callback-based services: a Callback interface with a method invoked when the asynchronous process was successful and one invoked when ...
Read more >Rules for Operators - Scala Documentation
The rules for infix operators have changed in some parts: First, an alphanumeric method can be used as an infix operator only if...
Read more >6. Expressions — Python 3.11.1 documentation
Some additional rules apply for certain operators (e.g., a string as a left argument to the '%' operator). Extensions must define their own...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Not sure if
UI {}
won’t be confused withlaunch(UI) {}
@LouisCAD 👍 Let’s try it as an extension for
CoroutineDispatcher
. We should start with an experimentalinline
function – it adds less weight to our public API. A member for this purpose is not Kotlinish. If the feedback is positive, then we’ll stabilize it after one release cycle.