Allow passing type name as a function parameter without typeof.

[edward-a]

E.g.

class A
{
    void Method(object x) {
    }

    void Run() {
        Method(A); // Instead of Method(typeof(A))
    }
}

Why it's needed:

1. Allows writing code generators that consume only syntax trees (no semantics) and dynamically determine operand type and what to do with it.
2. Syntax sugar.

Dart has this implemented and it comes very handy when writing code generators.

Update: As some have pointed out, the proposal may too much concentrate on the particular needs of OP. The suggestions is to focus on the syntax sugar part.

[svick]

I don't understand, why would a code generator be able to process Method(A), but not Method(typeof(A))? Especially considering that without semantics, A is more ambiguous than typeof(A), because A could reference a member or a local, while typeof(A) clearly references a type.

[edward-a]

I don't understand, why would a code generator be able to process Method(A), but not Method(typeof(A))? Especially considering that without semantics, A is more ambiguous than typeof(A), because A could reference a member or a local, while typeof(A) clearly references a type.

Because generator doesn't have type info on this identifier since it's only dealing with syntax trees. Consider parsing an expression. Some identifiers will represent variables while others are class names. Having a way to pass all expression parameters into a function that dynamically decides what to do with those makes possible to write code generators that would rather obtain type info dynamically than deal with clumsy and hard-to-implement semantics analysis.

[CyrusNajmabadi]

Because generator doesn't have type info

Why not update the generator to have type info?

[edward-a]

Because generator doesn't have type info

Why not update the generator to have type info?

Roslyn semantics analysis is very sluggish compared to syntax. There is a faster alternative which is building project separately with MSBuild and extracting type info through reflection wherever changes occur but this entails quite an amount of work and support.

[svick]

@edward-a If you want to, you can easily remove typeof from your code, for example by using CSharpSyntaxRewriter:

class RemoveTypeofVisitor : CSharpSyntaxRewriter
{
    public override SyntaxNode VisitTypeOfExpression(TypeOfExpressionSyntax node)
        => node.Type;
}

…

new RemoveTypeofVisitor().Visit(node)

The result of this will not be semantically correct, but I don't think that matters to you.

If you use this to preprocess code with typeof, your generator will only see the code in the form you like. I don't see why would this require changing the language.

[edward-a]

@edward-a If you want to, you can easily remove typeof from your code, for example by using CSharpSyntaxRewriter:

class RemoveTypeofVisitor : CSharpSyntaxRewriter
{
    public override SyntaxNode VisitTypeOfExpression(TypeOfExpressionSyntax node)
        => node.Type;
}

…

new RemoveTypeofVisitor().Visit(node)

The result of this will not be semantically correct, but I don't think that matters to you.

If you use this to preprocess code with typeof, your generator will only see the code in the form you like. I don't see why would this require changing the language.

The source code is an expression and has to be compilabe. E.g. a = b + Math.Abs(c). To obtain type info dynamically in the generated code I need to be able to make a call like G(b, Math, Math.Abs, c). Second parameter is the problem.

[CyrusNajmabadi]

Roslyn semantics analysis is very sluggish compared to syntax.

That's surprising to me. After all, semantic analysis needs to run in the sub-milliseconds range in order to support things like intellisense.

[CyrusNajmabadi]

The source code is an expression and has to be compilabe.

That would be the case with: Method(typeof(A)). It would be compilable. You would then just trim out the typeof portion yourself when doing the source transformation.

To obtain type info dynamically in the generated code I need to be able to make a call like G(b, Math, Math.Abs, c). Second parameter is the problem.

So have it be G(b, typeof(Math), Math.Abs, c), then when doing your transformation, convert typeof as you desire.

[edward-a]

Roslyn semantics analysis is very sluggish compared to syntax.

That's surprising to me. After all, semantic analysis needs to run in the sub-milliseconds range in order to support things like intellisense.

It's super slow if you use from code.

[edward-a]

The source code is an expression and has to be compilabe.

That would be the case with: Method(typeof(A)). It would be compilable. You would then just trim out the typeof portion yourself when doing the source transformation.

To obtain type info dynamically in the generated code I need to be able to make a call like G(b, Math, Math.Abs, c). Second parameter is the problem.

So have it be G(b, typeof(Math), Math.Abs, c), then when doing your transformation, convert typeof as you desire.

Code generator doesn't know which member to wrap with typeof because it doesn't have type info from the semantic analysis. It's only dealing with expressions like a = b + Math.Abs(c)

[svick]

@edward-a

The source code is an expression and has to be compilabe. E.g. a = b + Math.Abs(c). To obtain type info dynamically in the generated code I need to be able to make a call like G(b, Math, Math.Abs, c). Second parameter is the problem.

Isn't the third parameter also a problem? For this code to compile, G would have to have an overload that accepts Func<int, int> and I don't think there's a reasonable way of having that without semantic analysis.

[CyrusNajmabadi]

It's super slow if you use from code.

I don't know what this means. I use Roslyn "from code" all the time, and i can do tons of semantic operations per second without any issue.

[CyrusNajmabadi]

Code generator doesn't know which member to wrap with typeof because it doesn't have type info from the semantic analysis. It's only dealing with expressions like a = b + Math.Abs(c)

i don't see how this could work effectively for so many cases in C#. It's not just types that cannot be passed effectively do object. Lots of other constructs don't have implicit conversions either. Can you clarify how you would expect those to work?

[CyrusNajmabadi]

because it doesn't have type info from the semantic analysis.

I still need a good explanation of why using Roslyn to get this type information is out of scope.

I just checked and i was able to do 1 million semantic model operations in roslyn in just over 2 seconds. This was on a file like:

using System;
class C {
    void Foo(int a, int b) {
        var x = a + Math.Abs(b);
    }
    static void Main() { }
}

[edward-a]

@edward-a

The source code is an expression and has to be compilabe. E.g. a = b + Math.Abs(c). To obtain type info dynamically in the generated code I need to be able to make a call like G(b, Math, Math.Abs, c). Second parameter is the problem.

Isn't the third parameter also a problem? For this code to compile, G would have to have an overload that accepts Func<int, int> and I don't think there's a reasonable way of having that without semantic analysis.

Yes, it's a also a problem. But this problem is solvable since we only care about function return type to be able to parse member accesses like A.B(C).D.E. And since code generator already knows from the syntax it's a method call, we can use the code below to wrap the function and obtain it's return type dynamically:

    class FuncWrapper<T>
    {
      public static FuncWrapper<T> Create(Func<T> f) {
        return new FuncWrapper<T>();
      }
    }

    class FuncWrapperFactory
    {
      public static FuncWrapper<T> Create<T>(Func<T> f) {
        return new FuncWrapper<T>();
      }
    }  
    
    G(b, Math, FuncWrapperFactory.Create(() => System.Math.Abs(c)), c)

[FiniteReality]

The code example in the OP is a little odd and I don't follow the logic of code generators benefiting from this, but for a method,

void Foo(Type x) { ...

being able to call it via Foo(SomeType) rather than Foo(typeof(SomeType)) definitely feels more elegant and removes some pointless "noise", so I'm generally in favour of this proposal.

I'd generally agree, but it would be a source breaking change. For example:

static class CallerHelpers
{
    internal static void Call(Type callerType) { throw null; }
    internal static void Call(Caller caller) { throw null; }
}

class CallerInfo
{
    public Caller Caller { get; set; }

    public void DoSomething()
    {
        CallerHelpers.Call(Caller);
    }
}

In this case, while contrived, CallerInfo.DoSomething can only call CallerHelpers.Call(Caller caller) currently. If we allowed passing type names as a parameter without typeof, this would break the code as it is now ambiguous between CallerHelpers.Call(this.Caller) and CallerHelpers.Call(typeof(Caller)).

I've seen code not entirely unlike this in multiple codebases.

[DavidArno]

@FiniteReality, ah good point re breaking change conflicts like that. Oh well, back to the drawing board 😄

[edward-a]

The code example in the OP is a little odd and I don't follow the logic of code generators benefiting from this, but for a method,

void Foo(Type x) { ...

being able to call it via Foo(SomeType) rather than Foo(typeof(SomeType)) definitely feels more elegant and removes some pointless "noise", so I'm generally in favour of this proposal.

I'd generally agree, but it would be a source breaking change. For example:

static class CallerHelpers
{
    internal static void Call(Type callerType) { throw null; }
    internal static void Call(Caller caller) { throw null; }
}

class CallerInfo
{
    public Caller Caller { get; set; }

    public void DoSomething()
    {
        CallerHelpers.Call(Caller);
    }
}

In this case, while contrived, CallerInfo.DoSomething can only call CallerHelpers.Call(Caller caller) currently. If we allowed passing type names as a parameter without typeof, this would break the code as it is now ambiguous between CallerHelpers.Call(this.Caller) and CallerHelpers.Call(typeof(Caller)).

I've seen code not entirely unlike this in multiple codebases.

I believe this gets resolved easily by making compiler choose the second method in such cases. Or am i missing something?

[HaloFour]

It complicates the implementation. For a proposal that basically benefits a single person writing a very niche tool that intentionally skips using the built-in components for syntax analysis it's already exceptionally unlikely to be considered. Upping the difficulty, by any degree, only further ensures this.

[edward-a]

that intentionally skips using the built-in components for syntax analysis.

That is just not true. The syntax analysis components are fully utilized. But anyway, i suggest skipping on the OP's particular needs and review the syntax sugar benefits and complications. Updated the OP's post appropriately.

[HaloFour]

Eliminating 8 characters around a relatively uncommon operation doesn't seem like a particularly big benefit, especially since it involves the compiler having to interpret the token as potentially two different types of identifiers. Even eliminating the whole syntax analysis and source generator use case as described in the OP there's so little benefit here.

[FiniteReality]

In most cases in generators, you know whether something is going to be used as a type or a variable anyway, since you're the one generating the code. I can't think of a case where this isn't the case, and even in generators which aren't based on Roslyn you could probably use some form of tagging to indicate whether a value is a type or not.

[edward-a]

In most cases in generators, you know whether something is going to be used as a type or a variable anyway, since you're the one generating the code.

The generated code is based on expressions written in C#, so without semantics there is no way to statically resolve whether a type or variable is used for member accessing. It should be possible to resolve dynamically if the proposal goes through.

[Joe4evr]

I believe this gets resolved easily by making compiler choose the second method in such cases. Or am i missing something?

That would be a big change in behavior.

The generated code is based on expressions written in C#

Can you give an example expression and how your generator interprets that to cause this ambiguity?

[edward-a]

I believe this gets resolved easily by making compiler choose the second method in such cases. Or am i missing something?

That would be a big change in behavior.

Can you elaborate on this? It doesn't seem that it changes the current behavior, although i might be missing something here.

The generated code is based on expressions written in C#

Can you give an example expression and how your generator interprets that to cause this ambiguity?

The simplest example would be accessing static class member, e.g. Math.Abs(). There is no way to know if Math is a type or variable from syntax analysis. You could however figure this out if you were able to pass Math as an argument to a function and use reflection.

[Joe4evr]

Can you elaborate on this? It doesn't seem that it changes the current behavior, although i might be missing something here.

As stated, code currently can only pick the first overload. However, with the change you've suggested, that same code will suddenly pick the second overload on recompilation, which is s a change in behavior and violates the Principle of Least Surprise.

[edward-a]

Can you elaborate on this? It doesn't seem that it changes the current behavior, although i might be missing something here.

As stated, code currently can only pick the first overload. However, with the change you've suggested, that same code will suddenly pick the second overload on recompilation, which is s a change in behavior and violates the Principle of Least Surprise.

I don't see it picking up the first overload, it's definitively the second overload that gets called in DoSomething.

static class CallerHelpers
{
    internal static void Call(Type callerType) { throw null; }
    internal static void Call(Caller caller) { throw null; }
}

class CallerInfo
{
    public Caller Caller { get; set; }

    public void DoSomething()
    {
        CallerHelpers.Call(Caller);
    }
}

Implementing the proposal and making compiler favor the second call over first doesn't seem to change current behavior.

[Joe4evr]

Oh, that's my bad; I thought Call(Type) was the second overload (which made a lot of sense in my head since a reflection-based overload should be a lower priority than a non-reflection one).

[SteffenBlake]

I would enjoy this as well, many times I have methods that take in a string as a "nameof" that they want to receive, but I have no way to enforce that.

I would simply expect the syntax to be a variable that is coalesced to a stringifiable variable via nameof, automatically, but still retains the type safety if needed. IE I may still want to specify "I will want the name of this variable, but that variable still needs to be an int!"

public void LogIntName(name<int> n) {
    // n will be a 'nameof'<int> here, which can be handled as a string.
    Console.WriteLine(n);
}

var foo = 5;
var bar = 6;

LogIntName(foo); // Writes "foo" to the console
LogIntName(bar); // writes "bar" to the console=

Something like this.

[yaakov-h]

@SteffenBlake that sounds more like #287 to me.