On 29.09.2023 18:30, Guillaume Piolat wrote:
On Friday, 29 September 2023 at 15:00:33 UTC, Imperatorn wrote:
I think for this to be truly valuable, it would require being part of
the language.
Only if proven on DUB.
I admit I haven't really thought about implicit parameters before your
post, so I might be missing something.
Think of it like envvars for threads. When you launch a process, the
launcher knows to copy the environment variables. With scattered TLS
variables, no new thread can get a copy of all the "context" it may
have. But with a centralized place for context, you will be able to do
that (not implemented yet), which kinda improves encapsulation.
**Example 1: Context variables are scoped**
In a UI library, every new widget typically get a "UI context" (that,
or factory functions only) polluting all the constructors there is.
Solution: Just append "uiContext" variable in the context => less
parameters.
But it could be a TLS variable, right? Yes indeed, but then you may want
to scope that, to remove the global from being accessed outside a
particular scope. Globals can be accessed at any time, which doesn't
improve a public API.
**Example 2**
When my "gfm" package was forked to "gfm7", the first thing that was
done is:
- remove all the _gl members that would only there to confirm a
particular shared library was used => it is part of the context
- and removed all logger interface passing => also ugly and kinda never
changes
But later I understand that the removing of gl has also disadvantages.
In general implicit context is really the great idea
