Allow implicit out parameter casting

[craylton]

// Instead of writing this:
bool success = int.TryParse("5", out int i);
double d1 = i;

// I propose we can write this:
bool success = int.TryParse("5", out double d2);

I'm far from an expert, but since an int can be implicitly cast to a double, I don't see a good reason why this shouldn't be possible.
(Yes I realise there is a double.TryParse method - the above example is only for demonstration)
Here's a real-world example of where I've had to work around this issue. In this code a ushort can be implicitly cast to a FaultCode.

if (!modbus.TryReadSingleRegister(register, out ushort response))
    return false;

FaultCode faultCode = response; // I shouldn't need to do this

if (faultCode.IsFault)
{
    ErrorReceived?.Invoke(this, faultCode.ToString());
    // ...
}

[HaloFour]

ref and out parameters pass an address to the local/field and are required to be the exact same type. The only way that the compiler could do some kind of conversion would be to emit a temporary local variable, pass the address to that, and then copy the value from the temporary value to where you intend to have it written. But that would change the semantics of how ref/out work as currently when the method writes to that address that change is observable immediately, but if the address were to a temporary local that change wouldn't be observable until the method returns, or possibly at all if the method throws.

[HaloFour]

For your use case I might suggest writing an extension method:

public static class ModBusExtensions {
    public static bool TryReadSingleRegister(this ModBus modbus, Register register, out FaultCode faultCode) {
        bool result = modbus.TryReadSingleRegister(register, out ushort response);
        faultCode = response;
        return result;
    }
}

[KalleOlaviNiemitalo]

Properties as out/ref parameters (#748) would likewise need a temporary variable.

The main objection there seems to be that the implicit assignment back to the property (or in your case, to the differently-typed variable) would happen only after the call finishes, and that could cause bugs that would be difficult for developers to notice. However, if a special (but brief) syntax were required at the call site to indicate that something unusual is going on, I think that would reduce the risk.

modbus.TryReadSingleRegister(register, out ushort = FaultCode faultCode)

• pro: Can resolve overloads by specifying another type instead of ushort.
• con: The assignment looks like it will execute in reverse direction. It would make more sense with ref, though.

modbus.TryReadSingleRegister(register, FaultCode faultCode = out ushort)

• pro: The assignment goes in the correct direction.
• con: Risks clashing with the = ref reference reassignment syntax.

modbus.TryReadSingleRegister(register, out (ushort) FaultCode faultCode)

• con: The cast syntax suggests that narrowing conversions are also allowed.
• con: Risks clashing with 1-tuple interpretation of (ushort).

I don't really like any of these. Perhaps a nicer syntax would be possible with as or is or : or =>.

[dsaf]

Can we have a compiler flag to disable all implicit conversions instead, just like F#?

[john-h-k]

@dsaf C# team specifically want to avoid "dialects" of C# like that would create

[CyrusNajmabadi]

@dsaf You can write an analyzer to find and flag all implicit conversions if you don't like them.

[dsaf]

@CyrusNajmabadi true, but this is not the kind of thing I would like to own and add to every project.

[dsaf]

@johnkellyoxford are you sure that is still the case? Nullable reference types will be opt-in and there will be feature disparity between .NET Core and .NET Framework.

[Mteheran]

I understand the purpose of this feature but for this case why not use double.TryParse

[HaloFour]

@dsaf

are you sure that is still the case? Nullable reference types will be opt-in and there will be feature disparity between .NET Core and .NET Framework.

Indeed, NRTs creates a dialect. But the team considers trying to solve/mitigate the "billion dollar mistake" to be of a high enough bar. I expect such a change to be exceptionally rare, especially considering that the cost of each new dialect is quadratic.

As for the feature disparity between .NET Framework and .NET Core, that is unfortunately expected as .NET Framework is very unlikely to be considered for any future runtime changes. It's unfortunate for a lot of developers who don't have the ability to migrate, but it would be terribly poor planning on the C# team's part to only consider language changes that didn't require runtime changes.

[yaakov-h]

Feature disparity between .NET Framework and .NET Core is not that much different to feature disparity between older .NET Framework and newer .NET Framework.

You can't use LINQ on .NET 2.0 or async/await on .NET 4.0 etc., at least not without polyfills. This has always been the case for language features that require runtime support.

That's not quite the same as splitting the language into dialects.

[theunrepentantgeek]

I expect such a change to be exceptionally rare, especially considering that the cost of each new dialect is quadratic.

I'm pretty sure the cost of each new dialect option is exponential - if you have (heaven forbit) 8 options to toggle, that's 256 dialects of the language to consider. Ouch!

[CyrusNajmabadi]

@CyrusNajmabadi true, but this is not the kind of thing I would like to own and add to every project.

It would be probably a dozen or so lines of code. Seems like a minor thing to add to your project, and probably 4-5 orders of magnitude cheaper than having the C# team have to make and support that flag forever.

Honestly, i think you could literally just write:

    [DiagnosticAnalyzer(LanguageNames.CSharp, LanguageNames.VisualBasic)]
    internal class NoImplicitConversionsDiagnosticAnalyzer : DiagnosticAnalyzer
    {
        public override void Initialize(AnalysisContext context)
        {
            context.EnableConcurrentExecution();
            context.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags.None);

            context.RegisterOperationAction(c =>
            {
                var conversion = ((IConversionOperation)c.Operation).Conversion;
                if (conversion.IsImplicit && !conversion.IsIdentity)
                    c.ReportDiagnostic(Diagnostic.Create(descriptor, c.Operation.Syntax.GetLocation()));
            }, OperationKind.Conversion);
        }
    }

That's really about it (modulo you tweaking what sorts of conversions to report on if the above isn't quite what you want.

Analyzers were literally created (and are heavily supported) precisely for the use case of someone coming along and saying: is there a way for me to have a compiler witch to get an error on this legal C# code?

Instead of the compiler having to have literally thousands of switches (since there are that many requests for custom errors and more), the compiler is simply extensible and you can create your one-off errors for the things you don't like.