Permit non-void return types for partial methods (VS 16.8, .NET 5)

[AaronRobinsonMSFT]

The Source Generator feature is being investigated to create a runtime agnostic and AOT compatible P/Invoke stub generator. One of the hard requirements of Source Generators is user written code is read only and cannot be altered by any Source Generator implementation. This requirement makes it difficult to declare methods and use them, but have a Source Generator provide an implementation in the future (i.e. build time).

Possible work-arounds exist by declaring a partial class and having a convention.

// User defined
[FutureMethod("Foo", typeof(int))]
partial class GenClasses
{
}

// Generated in another TU
partial class GenClasses
{
   public static int Foo() { ... }
}

The above could be made to work, but there are issues.

• How does documentation for Foo work?
• What is the IDE scenario here for IntelliSense?
• Users would probably see many red squiggles that make development annoying.

An alternative approach would be a type of forward declaration using partial methods. The below would relax the requirement to have a void return type and thus the generation of the corresponding method could occur. IntelliSense would make sense as would a location for XML documentation in the user defined code.

Note partial methods are also required to be private. The below example does adhere to that requirement, but relaxing that would also be beneficial although not strictly needed.

// User defined
partial class GenClasses
{
   static partial int FooImpl();
   public static Foo() { return FooImpl(); }
}

// Generated in another TU
partial class GenClasses
{
   static partial int FooImpl() { ... }
}

/cc @jaredpar @davidwrighton @jkotas @stephentoub

[YairHalberstadt]

I presume that unlike void private methods, an implementation of the partial method would be required?

[AaronRobinsonMSFT]

@YairHalberstadt I personally have no objections to that, but it would be up to the language teams to make the final decision. I would imagine some complexity if that wasn't the case though.

[agocke]

I independently thought of the same thing when @chsienki and I were brainstorming a while ago. Seems useful. I assumed that non-void return types would require an implementation method.

[jaredpar]

I presume that unlike void private methods, an implementation of the partial method would be required?

Yes indeed. It would also mean that partial methods which have non-void return methods cannot be erased at the call site; there will always be an invocation of the method.

partial methods are also required to be private. The below example does adhere to that requirement, but relaxing that would also be beneficial although not strictly needed.

I think we'd also want to lift that restriction. Think the best way to approach that part is to say that partial methods which have a non-private accessibility are required to have an implementation. That gives it similar rules as non-void return types.

[tannergooding]

If private void partial-methods are not required, and non-void partial methods (any accessibility) are required, would non-private void partial methods be required?

Would it be worth something allowing the user to specify that the void partial method (any accessibility) is required to help catch issues where they expect it to be provided by a source generator and want to error if it isn't?

[tannergooding]

(To clarify, I mean a specific instance is required so we don't break back-compat).

[333fred]

non-private void should almost certainly be required. They're part of a public api, and having them silently do nothing would break abstraction boundaries.

[jaredpar]

@tannergooding

If private void partial-methods are not required, and non-void partial methods (any accessibility) are required, would non-private void partial methods be required?

Yes. As my comment said: partial methods which have a non-private accessibility are required to have an implementation. I deliberately left out return type in that statement.

Would it be worth something allowing the user to specify that the void partial method (any accessibility) is required to help catch issues where they expect it to be provided by a source generator and want to error if it isn't?

Possibly but I'd wait to see a compelling case before adding a new feature to support this. So far we've been discussing relaxing existing restrictions to support source generators. This would be adding a new restriction and is essentially a new feature (need syntax or attribute to support).

[alrz]

Previous discussion: #753

[AaronRobinsonMSFT]

Previous discussion: #753

@alrz That is definitely being discussed here. Should we close that issue in lieu of this one since this is a super-set?

[alrz]

Should we close that issue in lieu of this one since this is a super-set?

Sure, just wanted to add the link just in case. Closed.

[CyrusNajmabadi]

I don't actually understand the need here for this. Addressing hte OP:

How does documentation for Foo work?

The generated Foo includes its documentation. That documentation flows along the same way as nodemal code.

What is the IDE scenario here for IntelliSense?

IDE works because it sees the generated code.

Users would probably see many red squiggles that make development annoying.

That should not happen. The source generator will run and will have generated the method the user can call.

a

[AaronRobinsonMSFT]

How does documentation for Foo work?

The generated Foo includes its documentation. That documentation flows along the same way as nodemal code.

The auto-generated code isn't what the user wrote, so how would it know the documentation for the API? In the below code, where does the XML documentation for the function Foo reside? Any existing documentation tool would be confused by documenting the attribute with the typical XML documentation for a method.

// User defined
[FutureMethod("Foo", typeof(int))]
partial class GenClasses
{
}

What is the IDE scenario here for IntelliSense?

IDE works because it sees the generated code.

That is only true if source generators are continually running in the background. It is entirely possible for this to work similar to XAML, but there are terrible cases there especially during a copy/paste of large swathes of XAML where the editor needs to wait for the language service to keep up. There would be squiggles and general confusion since Foo's signature is being generated and defined by the user in a dynamic manner. As opposed to XAML where there is an inheritance contract to conform to and possibly optimize for the limited set of API signatures that would exist.

In the proposed case, there is a function declaration a head of time which satisfies the location for XML documentation and completely addresses the IntelliSense issue without putting undo pressure on the IDE to try and generate potentially large amounts of code during the edit cycle.

[stephentoub]

The generated Foo includes its documentation. That documentation flows along the same way as nodemal code.

Flows from where?

Let's say this is a regex generator. I want to be able to write this:

/// <summary>Creates a regex that finds hello followed by world, with anything in the middle</summary>
[RegexGenerator("hello.*world", RegexOptions.IgnoreCase)]
internal static partial Regex HelloWorldRegex();

With that I don't have to have a string-based name. I've written the method I'll be calling like any other, except the generator is filling in the implementation, rather than the method magically appearing out of thing air. I've been able to put documentation on the method like I would on any other method. The regular expression that's tied to this method is right there in the method's attribute, not somewhere else in the assembly attributing some less specific thing. Etc.

How does this look without the non-void returning support?