Exponentiation operator (^) should recognize Pow methods

[AnthonyDGreen]

F#'s exponentiation operator (**) looks for a Shared Pow method that takes its operands. We should consider this flexibility in VB since most math libraries don't support VB's op_Exponentiation specialname method. This would make the native VB syntax work with, for example, System.Numerics.BigInteger.

[tannergooding]

@AnthonyDGreen, what about special "well-known" cases (Math.Pow for Double and MathF.Pow for Single -- the latter is only on NetCore currently) where they are members of a separate static class in corlib?

[AnthonyDGreen]

Well today VB translates ^ into Math.Pow for the built in types. Not sure about accommodating MathF.Power.

We also have this idea (elsewhere) about extension statics so maybe we could bridge the gap that way.

[franzalex]

@AnthonyDGreen I am in support of your proposal. What though, do you mean about extension statics?

[AnthonyDGreen]

@franzalex it's a proposal we've been discussing for several years to allow you to add Shared members to an existing class the way you can add instance methods. So, for example, during the development of Async and Await we wanted to add new factory methods to the Task type (which shipped in the .NET Framework). Since we couldn't do that in a standalone package we shipped another type in our own library called TaskEx where the new prototype factory methods could be found. This was less than ideal. If we had extension Shared methods then Pow methods could be added to the types @tannergooding mentioned and it would be easy for the compiler to find them. It's certainly less chaotic than full on extension operators.

The problem though with extension Shared members is that they're caught up waiting on a grand unified proposal of "Extension Everything". We did some prototype work on it last summer and our hope is to have a generalized feature that lets you make more than just extension instance methods.

[franzalex]

Now that would be very welcome. It would lead to less-than-ideal situations when writing code.

I remember having to use conditional compilation to map and remap Task and TaskEx depending on which version of the .NET framework was being targeted. Though I got it to work, I couldn't help but think, "couldn't this have been better?". Plus, there have been a few instances where I have desired to have extension methods bound to the class being extended rather than an instance of that class.

Overall, I think extending extension methods to cover more than just an instance of a type will be generally a welcome idea.