Anonymous fields

[eelstork]

C# has support for anonymous functions. Anonymous functions are useful, in that they avoid explicitly naming functions which are used only once (DRY principle) and may be tied to their call site (closures).

Likewise, an anonymous field provides instance/static storage tied to a specific call site. This is helpful when a function requires storage, which:

• From the caller's point of view is an implementation detail which needs not (or must not) be exposed (hiding, encapsulation).
• From the function implementer's point of view, should be supplied by the caller (storage management)

To illustrate, let's assume a function F(implicit ref T foo).

implicit ref T foo is used to specify anonymous storage, so that every occurence of F(); in the definition of a class X requires a T F_fooN; field to be implicitly created by the compiler.

I have implemented a library which relies on anonymous fields. The strategy used to implement this in C# 7 is hackish (via caller information); however a couple of examples taken from the library (which may be appraised out of context) will clarify how anonymous fields may be used.

I also provide an example from another API, which does not (but could) take advantage of anonymous fields.

Currently, the closest I can think of (except anonymous functions) is the foreach loop, where the iterator is hidden from the user. A key difference is that foreach allocates function-local variables, not instance/static fields.

Use cases

Example 1 : Latch

Status s = Latch( cond )?[ task ];  // (1)

In the above, please assume that:

• an anonymous latch of type bool is used.
• Status is a three valued variable (running, failing or done).
• task is an expression which returns Status.
• The above is running periodically (update loop)

Initially the latch is blocking (false). Therefore, task will not be evaluated. If cond is true, the latch switches state (true); every subsequent invocation of (1) then proceeds as follows:

• if task is running, the latch value remains unchanged regardless of cond.
• if task is failing or done the latch resets to its initial value of false.

In summary, the Latch function implements a latch, which conditionally starts a timely/incremental task. Once the task has completed or failed, the latch resets.

In the above example:

• Every call to Latch implies storage, as if calling Latch(bool cond, ref bool latch)
• Every occurrence of Latch() in the source requires unique storage (call site binding) on a per object basis.

Having the API user allocate storage manually is not desirable.

• latch should always initialize to its default value of false.
• There are no good names for this kind of storage (latch1, latch2, ... is what a user might pick)
• Letting the user allocate storage is error prone; conflated storage may cause intermittent bugs.

NOTE: the Func( LHS ) ? [ RHS ] pattern as a whole is not relevant here; will detail on request, but I think it would be somewhat of a digression.

Example 2: Cooldown

Status s = Cooldown( duration )?[ task ];

In this case the Cooldown function implements a regular cooldown. As above, task is a status expression.

Initially the cooldown is passing (true). If task returns a value of failing or done, the cooldown then switches to blocking (false). Subsequently, the cooldown does not evaluate task until the specified duration (which may change throughout iterations) has elapsed.

Similar to the previous example, site-bound instance storage is needed (here, an object of type NS.Cooldown would be needed to store state (passing/blocking) and a time-stamp)

Example 3: Scroll-view position

This example is taken from a popular library, which uses a functional API to render user interface elements. Scrollable areas are implemented using the following idiom:

class MyView{

    Vector2 pos;

    void OnGUI(){
        pos = EditorGUILayout.BeginScrollView(pos);
        // render scrollable view content
        EditorGUILayout.EndScrollView();
    }

}

Again we see the same pattern emerging - site bound storage is required to provide the desired functionality. Meanwhile, there is an interesting difference: here it is sometimes meaningful for the user to modify pos in order to programmatically change the scroll position. Therefore we have cases where an anonymous, compiler generated field is wanted, and others where the user would prefer an explicitly declared field.

Suggested semantics

I propose using the implicit keyword to specify anonymous fields; the following signatures would then match the presented use cases:

// Latch method signature
public X Latch(implicit ref bool latch);  // (1)

// Cooldown method signature
public X Cooldown(float duration, implicit ref Ns.Cooldown cooldown);  // (2)

// Scrollview method signature
public void BeginScrollView(implicit ref Vector2 pos);  // (3)

(the type of X is irrelevant)

Disadvantages of current workarounds

As noted, implied storage has been implemented via caller information. For example, here is the current signature of the Latch method:

// Latch
public X Latch(bool cond, [CallerLineNumberAttribute] int key = -1);

CallerLineNumberAttribute is the closest we get to site-bound implied storage. As noted, this is hackish and error prone (extra steps are taken to avoid collisions but, in fine line numbers to do not uniquify function calls); unfortunately there are more shortages to this:

• Under the hood, storage needs to be allocated; without a compiler generated field, this leads to hashing, causing performance and memory overheads.
• In my primary use cases, the defined APIs are made to partake a base class, which the user then needs to extend. This is because the methods which require implied storage, are made to manage said storage on the client's behalf (or we'd have to also pass a reference to the calling object). Once the burden of managing this storage is moved elsewhere, these methods could be defined in a static class, and the base class is no longer needed.

Notes

Note 1

Throughout I have used implicit ref x to articulate the fact that the called function is responsible for initializing the value of an anonymous field. It may turn out that every use case requires ref - if so the ref keyword might be omitted.

Note 2

In those cases where the user may wish to rely on implicit storage allocation, or explicitly supply a reference, a separate keyword may be needed. optional came to mind but this looks headed towards a confusion with optional parameters. Meanwhile, actual optional parameter semantics may not be a good match for this.
For completeness, I note that, in my primary use cases, implicit storage allocation is always optional. This is because the programmer may wish to manually reset or configure the underlying services (latches, cooldowns, and others).

Note 3

Having no handle at all on anonymous fields is not desirable. At a minimum, I am assuming that these fields can still be addressed via reflection.

[CyrusNajmabadi]

This is helpful when a function requires storage

Isn't a function, with required storage, just a class? Why not just implement your libraries with classes that just keep track of their associated storage/state, and which clients interact with through an exported method?

[Unknown6656]

Isn't a function, with required storage, just a class? Why not just implement your libraries with classes that just keep track of their associated storage/state, and which clients interact with through an exported method?

I second this, however, I could see the point of method-scoped static (or maybe local) variables, e.g.:

public (int Globally, int InThisInstance) HowManyTimesWasThisFunctionCalled()
{
    static int g = 0; // only initialized once statically
    instance int i = 0; // only initialized once per instance

    return (++g, ++i);
}

which would be translated to something like this:

public class Class1
{
    // compiler generated
    private static int $_field1 = 0;
    private int $_field2 = 0;

    public (int Globally, int InThisInstance) HowManyTimesWasThisFunctionCalled()
    {
        return (++$_field1, ++$_field2);
    }	
}

[eelstork]

@CyrusNajmabadi this would have been practical except the storage needs to be call site bound on the caller side, not the implementing function's.
Also, managing that storage in the way you describe would require hashing, which hurts performance and causes memory overheads.
@Unknown6656 what you describe here is another feature, which already exists in some languages; this is not related to the issue I am describing.

[CyrusNajmabadi]

@CyrusNajmabadi this would have been practical except the storage needs to be call site bound on the caller side, not the implementing function's.

Why? Why can't hte caller provide the appropriate instance in they want to execute the function on?

Also, managing that storage in the way you describe would require hashing, which hurts performance and causes memory overheads.

I don't know what this means. Since you are allocating a class (or struct if you so wish) it can just keep whatever storage it needs already associated with it.

[eelstork]

@CyrusNajmabadi you are absolutely right, the caller should provide the appropriate instance; what is being discussed here is whether the compiler, or the user, should supply the declaration of said instance.
In every use case that I have discussed:

• For every call site associated with the called function, a unique instance of the storage type is needed.
• In common usage scenarios, there is no use for the instance of the storage type except as a helper to the called function.
• Being call site bound, the number of instances required is known at compile time.

In other words, the allocated storage is an implementation detail of the called function and, from the API user's point of view, having to explicitly declare instances of said storage type is at best a meaningless chore, and at worse providing an opportunity to err.

Going back to your initial comment ("isn't it just a class"), encapsulating the needed data and functionality using a class does not solve the problem; you would then have a type, whose instances, although intended to be call site bound, need to be named - which contradicts intended use, and enables misuse.

[CyrusNajmabadi]

For every call site associated with the called function, a unique instance of the storage type is needed.

Define 'call site associated with the called function'.

For example, say i have:

void Foo<T>()
{
    YourFunction();
}

if i call Foo<int>() vs. Foo<string>() are those separate callsites of 'YourFunction'?

being call site bound, the number of instances required is known at compile time.

What about:

class C
{
     void Foo() { YourFunction(); }
}

...

new C().Foo();
new C().Foo();

Is this a single callsite? You say that the number of instances is known at compile time. So in this case, this could only be a single callsite. but your OP says:

is used to specify anonymous storage, so that every occurence of F(); in the definition of a class X requires a T F_fooN; field to be implicitly created by the compiler.

Indicating that you get a (non-static) field in the class. So i don't see how you'd know the number of instances ahead of time.

[CyrusNajmabadi]

which contradicts intended use, and enables misuse.

Currently your use case is too vague to understand why existing solutions would be insufficient. I get that you're saying they're not sufficient. My point is that you haven't given a good enough explanation for why that is, and it's not self evident given your description.

Can you give a realistic use-case for why i'd want this feature and why existing approaches won't work well here?

[eelstork]

@CyrusNajmabadi I have provided three real world use cases for this. Let's consider the possible use taken from an existing, relatively (10+ years) mature library and expand on this; first without anonymous fields, and this is how the API is currently being used:

using static EditorGUILayout;

class MyView{

    Vector2 pos1, pos2, pos3;

    void OnGUI(){
        pos1 = BeginScrollView(pos1);  // call site 1
        // Render content of first scrollable view
        EndScrollView();
        pos2 = BeginScrollView(pos2);  // call site 2
        // Render content of 2nd scrollable view
        EndScrollView();
        pos3 = BeginScrollView(pos2);  // call site 3
        // Render content of 3rd scrollable view
        EndScrollView();
    }

}

As above from the API user point of view, having to declare pos1, pos2, pos3 is not meaningful. In short, the API user are enlisted into explicitly declaring and re-assigning pos1, pos2, pos3. This is clutter. Also, it is clearly open to misuse (did you notice that I forgot to rename pos2 to pos3 at the third call site?).

Let's modernize this example (no anonymous fields just yet):

class MyView{

    Vector2 pos1, pos2, pos3;

    void OnGUI(){
        BeginScrollView(ref pos1);  // call site 1
        // Render content of first scrollable view
        EndScrollView();
        BeginScrollView(ref pos2);  // call site 2
        // Render content of 2nd scrollable view
        EndScrollView();
        BeginScrollView(ref pos3);  // call site 3
        // Render content of 3rd scrollable view
        EndScrollView();
    }

}

We avoided some repetition. However the situation has not changed: the API user still does not care about explicitly storing pos1, pos2, pos3, which at best can only introduce errors.

Let's use anonymous fields.

class MyView{

    void OnGUI(){
        BeginScrollView();  // call site 1
        // Render content of first scrollable view
        EndScrollView();
        BeginScrollView();  // call site 2
        // Render content of 2nd scrollable view
        EndScrollView();
        BeginScrollView();  // call site 3
        // Render content of 3rd scrollable view
        EndScrollView();
    }

}

With BeginScrollView(implicit ref Vector2 scrollingPosition) the compiler knows that scrollingPosition is call site bound; declarations can be auto-generated and the number of call sites (3) is known at compile time; in all, the user does not need to get involved into managing an implementation detail of BeginScrollView.

As above, the API designer could have used a ScrollView class. It is better encapsulation, but feels out of place in a set of functional APIs. Also you would still have to declare, name, instantiate and invoke a method on an instance of ScrollView, whereas using anonymous fields, BeginScrollView() is one neat function call.

The term "call site" is used as defined here.

For want of a specific example related to my own use cases, see here and look at how Every and After are used.

[HaloFour]

declarations can be auto-generated and the number of call sites (3) is known at compile time

Stick some control statements in there and all of that goes out the window.

but feels out of place in a set of functional APIs.

Mutable state is much more out of place in a set of functional APIs. C# is an OOP language, it is idiomatic to use classes here to contain state. It doesn't make sense to bend the language in this manner because you don't want to use any of the myriad of facilities that already exist to support your scenarios.

[eelstork]

I will reframe this proposal, hoping to promote understanding, and appease OOP sensibilities.

Assume a stateful service represented by type T. By design, assume the service is intended to be used on a one instance per call site basis (see my illustration, below).
This means that, for each call site, we must declare (and possibly instantiate) T.

Now, let's further assume that the only use of the service is via a function F(). So, the service looks like this:

class T{

    public void F(){}

}

Now, illustrating how T is intended to be used:

class U{

    T t0 = new T(), t1 = new T();

    public void Use(){
        t0.F();
        t1.F();      
    }

}

As per the current implementation of T, there is no way to enforce call site binding ('one instance per call site'). In other words, this compiles (detecting incorrect uses at runtime is also difficult):

class U{

    T t = new T();

    public void Use(){
        t.F();
        t.F();      
    }

}

Therefore, I am suggesting the use of anonymous fields, where T is now defined as:

class T{

    public void Imp(){ ... }

    static void F(implicit T arg) => arg.Imp();

}

Finally, illustrating how the service can now be used safely, assuming compiler generated, anonymous members (and their mandated uses):

class U{

    // T t0 = new T(), t1 = new T();  // auto-generated

    public void Use(){
        T.F( /* t0 */ );  // argument supplied by the compiler
        T.F( /* t1 */ );  // argument supplied by the compiler
    }

}

Other than trying to refocus on the core issue being addressed, I removed uses of ref. In my opinion the original version is more coherent but, for simplicity in exposing the main idea, maybe it is a little clearer this way.

As to the APIs, patterns and libraries discussed above, they are offered for illustration purposes. Whether they are good APIs, bend the language, or anything else... Yes, if no good API can use the proposed enhancement, that is a problem.

Aside; primarily, I came across the proposed enhancement while designing a control framework. I am not about to "just stick some control statements in there".

[HaloFour]

@eelstork

Sounds like a design issue somewhat easily solvable via fluent APIs. That also gives you the advantage of being able to flow any state you want through the API without the consumer having to worry about it (or even be aware of it).:

class U {
    public void Use() {
        T.F() // call site 1
            .F() // call site 2
            .F(); // call site 3
    }
}

Combining with lambdas it also provides the scoping that allows you to avoid the Begin/End-style of functions and worrying about carrying state between them.

class U {
    public void Use() {
        T.ScrollView(() => {
            // do stuff with first scroll view here
        }).ScrollView(() => {
            // do stuff with second scroll view here
        }).ScrollView(() => {
            // do stuff with third scroll view here
        });
    }
}

[CyrusNajmabadi]

As above, the API designer could have used a ScrollView class. It is better encapsulation, but feels out of place in a set of functional APIs.

I don't see why it would feel out of place.

Also you would still have to declare, name, instantiate and invoke a method on an instance of ScrollView,

Which would make the code extremely clear and easy to reason about. If I see scrollView1.Begin(... then I know what's going on. However if I just have three calls to beginScrollView then I have no idea that each call is doing something differently.

--.

Your example also doesn't make sense since since each begin is paired with an end. But how could each actually be paired since there now is this implicit state and there's no way for end to access it?

[HaloFour]

You may also be interested in this proposal: #1151

It seeks to add something like Kotlin lambdas with receivers where the block is invoked with an implicit this on which instance methods may be called. That receiver can maintain that hidden state.

[eelstork]

@CyrusNajmabadi specifically in the case of the widget rendering API, each widget is rendered using a function call. Not one widget here is objectified, as such it would be a quirk/exception, hence feel "out of place" (or much of the API would have to evolve).

However in discussing this widget library my original intent was only to summon, as you might put it "real world" examples, by which I mean APIs which have matured, and been used over and over by many developers - this, in addition to my own examples, where anonymous fields have already been implemented, and feel helpful.

If I had to emit an opinion on the GUI framework, the best I might say here is that, compared to both OOP style (Java's Swing) and reactive (Qt's) the GUI framework referred here feels at once quirky, lightweight and effective. Mutating the UI is done via regular control flow statements, which feels refreshing and speedy compared to managing object hierarchies (Swing).

On whether naming the scroll views makes the code easier to reason about, I simply have a different opinion. I don't find either of these much easier or harder to reason about. To me, naming these scroll views doesn't feel more informative than labeling if statements would be. Sorry about that.
I feel somewhat guarded about arguments saying "it is more explicit this way". In programming, too much progress has been achieved by eliding things that experienced programmers felt should remain explicit. I would always ask why - why do you need this to remain explicit?

With that, if to you, one form feels more explicit and easier to reason with, I totally respect that.

You write: But how could each actually be paired since there now is this implicit state ?
The fields are implicit to the caller of the BeginScrollView function. I would have hoped it was clear from the examples I have provided, that the function declaring an implicit parameter uses this parameter as normal, nothing implicit on this end.

It is really essential, to further this conversation, that we both have a clear understanding of how the enhancement is supposed to work. If anything else is unclear, please ask again.

[CyrusNajmabadi]

@CyrusNajmabadi specifically in the case of the widget rendering API, each widget is rendered using a function call. Not one widget here is objectified, as such it would be a quirk/exception, hence feel "out of place" (or much of the API would have to evolve).

I'm not really understanding. If i have three scroll views... what is weird about having 'objects' for those three scroll views? It's the norm in practically every UI toolkit i've ever used. It's simple, easy to understand and solves the communication/state-encapsulation well. In other words, it doesn't actually seem like something that is actually a problem that i would want to not do.

You write: But how could each actually be paired since there now is this implicit state ?
The fields are implicit to the caller of the BeginScrollView function. I would have hoped it was clear from the examples I have provided, that the function declaring an implicit parameter uses this parameter as normal, nothing implicit on this end.

Yes. I understand that. but your example says:

        BeginScrollView();  // call site 1
        // Render content of first scrollable view
        EndScrollView();
        BeginScrollView();  // call site 2
        // Render content of 2nd scrollable view
        EndScrollView();
        BeginScrollView();  // call site 3
        // Render content of 3rd scrollable view
        EndScrollView();

You have three calls to EndScrollView, each seemingly paired with the preceding BeginScrollView. I'm pointing out that it's not clear to me at all (Versus, say, how @HaloFour has offered options) how those End calls get properly assocaited with the preceeding Begin calls given that the state is now implicit. What actually ties these together?

[eelstork]

@HaloFour goes without saying.

Already clarified that my proposed enhancement is about managing control state in either real-time or otherwise iterative processes, so there's at least a fair possibility that this is general enough to interest more than one library.

Surely given the many requests for clarification I am getting here, re- starting from the one example I understand best would not be harmful?

To me there isn't so much overlap between:

• Striving for concision and better encapsulation,
• Designing (E)DSLs.

[CyrusNajmabadi]

So, for reference, and clarity of purpose, I have a framework, which lets you write a step method like this:

public void Step() => TaskA() && Wait(1f) && TaskB() && Wait(0.5f) && TaskC();

Note: the statefulness here actually makes me feel like things are less clear. That's not the behavior i would have expected from any language.

I'm not sure how i could effectively reason about any language where flow control was implicitly stateful.

[CyrusNajmabadi]

Striving for concision

Being concise has to be balanced with being clear. What you're proposing here is actually somewhat radical. I don't mean that in a negative sense. Just in a true assessment of hte scale of what you're asking C# to potentially do. It's something extremely new, extremely different, and very much against the grain of where the language has come from so far.

That doesn't mean it shouldn't be done. But it does mean it has to be so super compelling that the benefits are obvious to lots of people immediately, thus making it worth the effort involved her.e So far, i'm not really seeing those benefits. In your examples so far, it actually doesn't seem to have helped things. It actively seems to make things more difficult to reason about, requiring a ton of knowledge and awareness of all this implicitness

--

Designing (E)DSLs.

Why do (E)DSLs need implicit state for flow control? Can you point to existing DSLs in other domains where that's the case?

[eelstork]

@CyrusNajmabadi state implicit to a function call is definitely not new to C# or other OOP languages so this isn't at issue here. It can be done statically, or instance bound. It can even be site-bound although doing it this way is a little clunky in C#6~8.
Unless I am mistaken, coroutines also fall in the category of (relatively) implicit, stateful control.
Anonymous functions capture variables from the surrounding context, in a way that can feel counter-intuitive.

I've been pretty clear that I'm not implementing an EDSL, let alone a DSL. Why should I worry about these? Another commenter brought this up.

Finally. To the extent that you are surprised, and trying to wrap your head around something that looks relatively new. In my opinion this is a good thing. If every suggested language enhancement just added a thin layer of polish, things would be pretty boring.

[eelstork]

I'll be very clear about why I insist that this isn't related to EDSLs.
My experience with EDSLs is like this:

• Draft a syntax that reads somewhat clearly (the DSL syntax).
• Somehow retrofit the syntax to an existing language (with an instant loss of clarity, as with fluent APIs) (the EDSL syntax)
• Probably build a kind of graph under the scenes, which reorders everything in the way the host language needs it.
• Marvel at the cutesy "makes sense if we forget that it's actually [name of host language here] code".
• Throw hands in the hair if anything goes wrong.

This might be okay for a number of applications (preferably a small percentage of the time put into any project) but, it produces code that's hard to debug (because what you're debugging isn't what you wrote), and doesn't feel native of the language its written in (almost definitionally). With an EDSL I've seen (Boost Spirit I think) just understanding compile time errors took considerable time.

I am here because I do not wish to write another EDSL.

What in my examples looks like a DSL? The use of conditional operators with three valued logic? A slightly intricate pattern for control flow ( Foo() ? [ EXP ] ).
No re-arranging is happening in there. Operators are used as intended; execution left to right, top to bottom.

[CyrusNajmabadi]

@CyrusNajmabadi state implicit to a function call is definitely not new to C# or other OOP languages so this isn't at issue here.

I specifically was referring to: "where flow control was implicitly stateful."

[CyrusNajmabadi]

Unless I am mistaken, coroutines also fall in the category of (relatively) implicit, stateful control.

How are they implicitly stateful flow control in C#?

[CyrusNajmabadi]

Anonymous functions capture variables from the surrounding context, in a way that can feel counter-intuitive.

They are not implicitly stateful. The state is all explicitly stated by the user.

[CyrusNajmabadi]

I've been pretty clear that I'm not implementing an EDSL, let alone a DSL. Why should I worry about these? Another commenter brought this up.

Sorry. Happy to table that then.

But, in that case, i still go back to:

I'd suggest finding use cases outside of this API/framework you've designed. Any language proposal requires a broad range of appeal to justify the cost in terms of effort, complexity and support.

Not only is your own personal use case not coming across as compelling every time i look at it, you're also not providing any other use cases where this feature actually appears to be a good thing.

[eelstork]

@CyrusNajmabadi in this case maybe the proposed enhancement does not interest you right now, which is fine - as I understand you don't regularly write user facing, interactive applications, or video games?

There's a big difference in how people perceive enhancements to a language, factoring:

• How often they face a problem, and how awkward/frustrated they feel when solving said problem.
• What are other (potentially much more frustrating) issues that they're trying to tackle (tree hides the forest)

With that, each programmer have their own style. In my daily practice I avoid co-routines; but they are popular with many game developers. Took me significant effort (and goodwill) just figuring why they use them, and how. End result still not using them, but some respect for how others approach them.

Please contribute something here. Repeating endlessly that you don't see the point of this (and you've been doing it from the very beginning, at a point where your understanding of the feature wasn't even that clear) is still just one vote out.

I dedicated time and effort to explaining this feature to you specifically. I'd be delighted if you could come with one case where you'd find it useful. Otherwise, never mind.

[theunrepentantgeek]

@eelstork I'm not sure that your attack on @CyrusNajmabadi is justified. I hope you're aware that this repo has a code of conduct.

The onus is on you - as the proposer of the feature - to clearly explain what it does and to provide a good motivation why existing solutions are so poor that language support is required.

So far, your explanations haven't made sense to me - and I suspect that I'm not the only one. I applaud @CyrusNajmabadi efforts to get you to clearly explain what it is that you want the compiler to do.

FWIW, I've read through this entire thread multiple times trying to understand what you're asking for - and I still have no idea at all.

[spydacarnage]

I'm glad it's not just me, then :-)

…

On Fri, 4 Oct 2019 at 10:32, Bevan Arps ***@***.***> wrote: @eelstork <https://github.com/eelstork> I'm not sure that your attack on @CyrusNajmabadi <https://github.com/CyrusNajmabadi> is justified. I hope you're aware that this repo has a code of conduct. The onus is on you - as the proposer of the feature - to clearly explain what it does and to provide a good motivation why existing solutions are so poor that language support is required. So far, your explanations haven't made sense to me - and I suspect that I'm not the only one. I applaud @CyrusNajmabadi <https://github.com/CyrusNajmabadi> efforts to get you to clearly explain what it is that you want the compiler to do. FWIW, I've read through this entire thread multiple times trying to understand what you're asking for - and I still have no idea at all. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/2824?email_source=notifications&email_token=ADIEDQOLHXGADTKJWJYTHJLQM4EUBA5CNFSM4I2EZFGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALDCQA#issuecomment-538325312>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADIEDQNI42HK2OMS6EK4SWDQM4EUBANCNFSM4I2EZFGA> .

[canton7]

There's a long discussion on Gitter where the OP explained their idea in a way which I was able to understand.

[CyrusNajmabadi]

Please contribute something here.

My goal is to be able to get the proposal to a point where it could be championed. You may not like that that means asking questions and seeking clarity in the areas I have. But it's vital to this actually being able to go anywhere and not just sit here going nowhere.

Cheers! :)

[eelstork]

@CyrusNajmabadi I've been appreciative of your efforts in seeking clarifications, and this wasn't meant to be taken as a sweeping statement, only signaling that I'm trying to avoid redundancy in the thread.