No error for unassigned out parameter, bug?

[thomaslevesque]

Just fixed a bug that was caused by an unassigned out parameter. Normally the compiler emits an error for this, but in this case it doesn't.

This code produces an error, as expected:

private string Test(out string x)
{
	return null;
}

CS0177 The out parameter 'x' must be assigned to before control leaves the current method

Same result when the parameter is int or DateTime.

But this one doesn't produce any error:

private string Test(out PathString x)
{
	return null;
}

(PathString is a readonly struct from Microsoft.AspNetCore.Http)

I also don't get an error if the parameter is a custom struct (e.g. struct Foo {}), whether it's readonly or not.

I'm not sure what's going on here. Why does it produce an error for some types, but not for others?

I get this behavior in C# 7 and 8, didn't check earlier versions.

Is there a logical explanation, or is it a bug in the compiler?

[thomaslevesque]

With a non-empty custom struct, I do get an error, which makes sense, I guess. But it doesn't explain the behavior with PathString, which isn't an empty struct.

[YairHalberstadt]

An empty struct won't error because a struct is considered assigned if all it's fields are assigned, and so an empty struct is always assigned.

[thomaslevesque]

An empty struct won't error because a struct is considered assigned if all it's fields are assigned, and so an empty struct is always assigned.

Yes, but PathString isn't an empty struct...

[HaloFour]

Are you working with a reference assembly? IIRC there was an issue that because reference structs lacked fields that the compiler could treat them as empty. I forget what the resolution was to resolve that.

[thomaslevesque]

Are you working with a reference assembly?

I think so, yes. I'm using the latest VS2019 Preview and the latest .NET Core 3 SDK.

IIRC there was an issue that because reference structs lacked fields that the compiler could treat them as empty. I forget what the resolution was to resolve that.

I also seem to remember something like that.

[thomaslevesque]

Related: https://github.com/dotnet/corefx/issues/28870

[thomaslevesque]

Related: dotnet/corefx#28870

But this issue is supposed be fixed...

[HaloFour]

If the fix for the issue was recreating the reference assemblies with the dummy field maybe that wasn't done for ASP.NET?

[thomaslevesque]

If the fix for the issue was recreating the reference assemblies with the dummy field maybe that wasn't done for ASP.NET?

Well, the reference definition of PathString does contain the dummy field:
https://github.com/aspnet/AspNetCore/blob/release/3.0-preview7/src/Http/Http.Abstractions/ref/Microsoft.AspNetCore.Http.Abstractions.netcoreapp3.0.cs#L321

And I checked on my machine, the reference assemby for Microsoft.AspNetCore.Http.Abstractions also contains the dummy field. So the problem must be somewhere else...

[yaakov-h]

Is this a language bug then, or a compiler bug?

[thomaslevesque]

Is this a language bug then, or a compiler bug?

Compiler, I think

[canton7]

This probably wants to be in dotnet/roslyn, then, rather than dotnet/csharplang

[thomaslevesque]

This probably wants to be in dotnet/roslyn, then, rather than dotnet/csharplang

Maybe... I don't have the rights to transfer the issue, though.

[svick]

As far as I can tell, this has the same source as dotnet/roslyn#29319: Roslyn intentionally ignores private reference type fields in referenced assemblies for purposes of definite assignment, to maintain compatibility.

Though it seems https://github.com/dotnet/roslyn/issues/33288 (of which this issue is a duplicate) indicates this might change in the future.

[333fred]

As this is a duplicate of a roslyn bug, I'm going to close this bug. If we want to make a language change, we can open one later.

[thomaslevesque]

Works for me. In the meantime I'll use the <Features>strict</Features> flag, which is a good thing anyway.