implicit-context v0.0.1

[Guillaume Piolat]

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