Support local scope for using static (to help with flag-style enums and more)

[techfan101]

This issue started life as a request to reduce code clutter when working with flag-style enums (#2282). However, some insightful comments from other contributors (@YairHalberstadt and @HaloFour) have made me more fully consider the problem.

The general problem is the repetition of C# type names when referencing static members. For me, this most often occurs with flag-style enums, but any feature addressing this problem need not be so limited.

The using static directive, introduced in C# 6, nicely addresses this on a module-wide basis. Upon revisiting this feature recently, it became apparent that it also, to my surprise, works for enum members.

Unfortunately, I seldom want to promote member name visibility module-wide. More often, the requirement is to promote it in a limited region of code. It would be nice if a similar solution existed that allowed this finer level of granularity.

I see two possible approaches. The first is to simply extend the syntax for the using static directive to a local block { … }.

For example, assuming MyEnum is an enum with members Member1, Member2, and Member3…

using static MyEnum
{
  if ((status & (Member1 | Member2 | Member3)  == 0)
    return;
  MyMethod(Member2);
}

I like this approach for its consistency, but in some circumstances it can be a bit verbose.

Instead of this, I’m intrigued by the prospect of extending the behavior of the Lamba expression operator (=>). Currently, parameters are specified on the left-hand side of this operator.

It would be nice if (alternatively) one could specify a C# type. To avoid the possibility of naming conflicts, between types and parameter names, I propose enclosing the C# type in angle brackets <...>. This is similar to when a C# type is used as a generic parameter.

I like this operator, because it already supports both expression and statement Lambdas. An example of an expression Lambda, adapted for this new feature, might look as follows:

If ((status & (<MyEnum> => Member1 | Member2 | Member3)) == 0)
  return;

Similarly, an example of a statement Lambda, adapted for this new feature, might look as follows:

<MyEnum> =>
{
  if ((status & (Member1 | Member2 | Member3))  == 0)
    return;
  MyMethod(Member2);
}

Additionally, if the expression consists of constants, it should be allowed inside attribute initializers. So, for example:

[MyAttribute(<MyEnum> => Member1 | Member2 | Member3)]

[john-h-k]

Like the idea, hate the proposed implementation. It a) makes it seem as if it is related to lambdas and b) the <> syntax I feel is ugly,clunky and conflicting with generics (even if it doesn't spec-wise). I prefer the using static block idea, that is visually pleasing imho, introduces no new keywords or syntax, and is immediately clear

[munael]

Should just allow using-namespace directives in local scope, to be honest.

So:

void foo() {
    using static MyEnum; // As well as plain `using` for namespaces
    if ((status & (Member1 | Member2 | Member3)  == 0)
      return;
    MyMethod(Member2);
}

For the second part, why not just extend using statement functionality to cover symbols (namespaces and statically-openable types) like variables?

It doesn't mean the same (no resources to manage here), but syntactically it matches rather well (restrict these imported symbols to this part of the code).

Allowing the plain using directive would at least allow:

{
    using Namespace;
    // use namespace
}
// can't use namespace

at least.

[techfan101]

@johnkellyoxford / @narfanar the original post proposed, and demonstrated, two possible solutions to the problem: a using static local block or a Lambda-style syntax. While I have a preference for the second solution (Lambda-style), either one would be fine with me. As with most things in life, each possibility has pros and cons.

A local using static block, which I mention first, and in the title, is the most consistent with existing syntax. I also agree it is the most aesthetically pleasing. However, it is limited to statements and would not support expressions. So, it is unclear, for instance, how it might be used within an attribute initializer.

The Lambda-style syntax, while admittedly ugly, supports both expressions and statements. For what its worth, the pre-existing Lambda syntax is (imho) similarly ugly, but I've gotten used to it over the years.

My preference is for function over form, but I'd be perfectly happy with either possibility :)

[munael]

@johnkellyoxford / @narfanar the original post proposed, and demonstrated, two possible solutions to the problem: a using static local block or a Lambda-style syntax. While I have a preference for the second solution (Lambda-style), either one would be fine with me. As with most things in life, each possibility has pros and cons.
My preference is for function over form, but I'd be perfectly happy with either possibility :)

emphasis added

This is where we at once differ and agree. Sorry, I wasn't too clear about that :[

Instead of a local using namespace block akin to the using statement block, I'm saying we might be better served by a local using namespace that's akin to the new inline using declaration.

Your point on usability in expression context is an issue for a lot of constructs and may deserve a whole discussion for it 🌮

[john-h-k]

But it is utterly unrelated to a lambda. Looking like a lambda would be wrong and confusing

[techfan101]

@narfanar I'm sorry. I'm not certain I follow your point.

Are you proposing that, in addition to using static MyTypeName { ... }, it might be nice to also support a similar idea with using MyNamespace { ... }?

If so, I agree.

Though, to be clear the pre-existing, module-wide using static MyTypeName and using MyNamespace directives do different things. My purpose in opening this issue is to request an extension to the behavior of the former.

Another similar extension that might be fun is using instance myInstance { ... } to promote the visibility of instance members. This is a feature that some other languages support.

Though, for either of these ideas, opening a separate issue might be more appropriate. I welcome the dicussion and (if I understand you correctly) its a great idea, but I worry that it won't get the visibility it deserves buried here in the comments.

[YairHalberstadt]

For the first part, this is part of #218

For the second I think there's very little chance of this happening. Lambdas mean a specific thing in C#, and adding another, completely unrelated meaning is only confusing.