Int64 needlessly coerced to Double even when receiver is known to be of type 'object'

[rotemdan]

var s = "a";

object result = s switch
{
	"a" => 12341234123412341L,
	"b" => 3.14,
	_ => throw new Exception("")
};

Console.WriteLine(Convert.ToInt64(result)); // Prints "12341234123412340"!

This code was given as a "fix" by a Roslyn analyzer suggestion. It changes the assigned value from 12341234123412341 to 12341234123412340. The original worked fine:

var s = "a";

object result;
switch (s)
{
	case "a":
		result = 12341234123412341L;
		break;
	case "b":
		result = 3.14;
		break;
	default:
		throw new Exception("");
};

Console.WriteLine(Convert.ToInt64(result)); // Prints "12341234123412341"!

I've reported this as an analyzer issue and a compiler issue but was told that fundamentally this behavior was "as per the language spec" and not a compiler issue (it was accepted as an analyzer issue).

So now I'm here. The fact that for several years, C#'s own analyzer suggested this code-breaking change as if it is was somehow "semantic-preserving" is by itself an evidence for how unintuitive and unexpected this behavior is.

Moreover, if I added a bool typed case to the switch expression, it would work fine!

var s = "a";

object result = s switch
{
	"a" => 12341234123412341L,
	"b" => 3.14,
	"c" => true,
	_ => throw new Exception("")
};

Console.WriteLine(Convert.ToInt64(result)); // Prints "12341234123412341"!

I've wasted hours of bug tracking only to eventually be told that the compiler behaved like this "as per the spec". It's mind-bending that by removing one case (here "c" => true) would significantly alter the behavior of the code.

Please consider sorting out your specifications to make them more predictable and useful for the programmer. Not just a set of arbitrary rules that have to blindly accepted as gospel. If the target type is object, it makes sense that the assigned value and type should be preserved as much as possible. That's the whole point of the object type.

[CyrusNajmabadi]

If the target type is object, it makes sense that the assigned value and type should be preserved as much as possible

A few things here. First, C# has since the very beginning had an idea that the inner 'best type' would win in cases like this. So, for example, if you have object o = x ? 0 : 1.0; then you would always get a double here. Not a double in some cases and an int in others.

In that regard, switch expressions behave like how constructs in the language always behaved.

That said, what we added later was that if there was no "best common type" of all the "arms" that we would allow external data to flow into the expression, instead of determining things just from the expression itself.

It's mind-bending that by removing one case (here "c" => true) would significantly alter the behavior of the code.

Sure. But inherently, what's going on is that we have a set of rules that say "if you can figure out the type this way, then do so" (because that's how the language worked from teh beginning). But then "if that fails, you can add these extra rules to make the type work". Thsi approach allows more code to succeed, while also maintaining back compat.

If the target type is object, it makes sense that the assigned value and type should be preserved as much as possible.

The problem with this is back compat. Tons of code is written with the rules prior to us adding support for 'target typing'. That code has meaning today, and would absolutely break tons of real world libs and apps that depend on that. So we have to accept the existing behavior, and only allow the new rules to come into play with teh original behavior would result in error. We can't have the new rules change the meaning of existing code.

[rotemdan]

@CyrusNajmabadi

Switch expressions were added in C# 8, long after target-based type resolution was added to the language.

Instead of using the opportunity to design switch expressions properly, the design team chose to conform to the "broken" behavior of conditional expressions, which also forces Int64 values to be implicitly cast to Double (Double is not even their "common type" since it is not a super-type Int64 as the back-and-forth conversion may cause loss of information).

The design team decided they would prefer to preserve this behavior as they believed it was somehow "better". This was not a forced decision, and it would not have broken anyone's code if they decided otherwise.

This does not seem like an issue of backwards compatibility, but of perceived semantic "consistency" between a new feature (switch expression) and an old one (conditional expression). However, since switch expressions have multiple cases, it amplifies the original error in design several times fold, without providing much benefit to the user.

I feel that this perceived "consistency" between the new and old is not really about end-user experience, but more of the "designer experience" or "aesthetic sense" of their language being a "whole" in some way. Most users don't know the language deep enough to "appreciate" this (non-)feature and they would rather it to "just work" as expected. As far as I'm concerned, this behavior means that it doesn't achieve that.

[jnm2]

The priority of these facts against all other considerations is far from shared, as you saw. The nice thing is that you can fix this Iack of safety in a few days by writing an analyzer. Analyzers are perfect for more highly opinionated users of the language without bringing the downsides (that are usually the flip side of the coin) on other users of the language

[tannergooding]

These are facts, not opinions:

The first two are definitely facts.

The third/fourth are a bit of an opinion, there is no right or wrong answer. You still have all the type safety, its only a matter of whether or not a conversion happens so the boxed values are the same, or different. The key here is that for the two input Type scenario, the language has always preferred double here (going back to C# 1.0, cond ? 0 : 1.0 has been "double"). The three+ input Type scenario, with target type object is a new, but is still overall consistent and double, ulong, byte still picks double. The interesting case is that when you add in any type that is not implicitly convertible to or from the other types (e.g. double, int, bool where bool is the "special-case"), then it has to fallback to checking the "target type", which is object.

The key here is that the overall language is consistent, regardless of whether you, I, or anyone else thinks the behavior is good or bad. The behavior for all aspects remains effectively the same and you aren't going to get into weird corner cases where the the assignment object o = cond ? 0 : 3.14; Console.WriteLine(o.GetType()) is System.Double (as it has been since C# v1.0) but the assignment object o = cond switch { case1 => 0, case2 => 3.14 }; Console.WriteLine(o.GetType()) is System.Int32 or System.Double.

In both cases, you have a single assignment expression and the type of that assignment expression is determined by its singular subexpression. Once you make it two assignment expressions (as required by the switch statement scenario), then the types of both subexpressions can't be considered in relation to eachother and it becomes "something different", but still consistent with how the language has always worked here.

[CyrusNajmabadi]

To tanner's point as well, if we were to do the language again, we could very possibly do things differently. However, we do view consistency with past, heavily used, constructs important.

I also agree with @jnm2 (and mentioned the same above). This is a great area for an analyzer. There is no doubt you dislike this language rule. In the case that we can't solve this, an analyzer would be valuable to write. You could have several rules. One about long->double conversion of you don't like that. One about target vs common type conversions.

I'd also be super happy to help write those analyzers. We have a very active discord where we help with that stuff a ton.

Note: when this topic came up during those discussions, I did an analysis of codebases we have access to (Roslyn, bcl, 2nd and 3rd parties, etc.). It turned out this 'better type' vs 'Target type' behavior is all over the place. Roslyn itself very much takes advantage of it.

We have to take this sort of thing into account in our language design.

[CyrusNajmabadi]

@rotemdan feel free to use discord.gg/csharp or https://aka.ms/dotnet-discord for analyzer help! Tanner, myself, and many others on the team (and external) participate there

[CyrusNajmabadi]

Note: we are discussing this issue, and others you raised there right now :-)

[DavidArno]

For what it's worth, you can override the default type inference:

var s = "a";

var result = s switch
{
	"a" => (object)12341234123412341L,
	"b" => 3.14,
	_ => throw new Exception("")
};

Console.WriteLine(Convert.ToInt64(result)); // Prints "12341234123412341"

But I would agree with you that there is a bug in the analyzer as it should be adding that (object) cast when refactoring as an analyzer refactor like this should not break code. As you point out via your link, Cyrus has already accepted it is a bug in the analyzer, so all is good there.

What cannot happen is for the compiler to suddenly change its type inference rules to work in the way you feel they should. That would seriously break vast amounts of existing code. Whether the way the rules work now is the right design choice or not is a moot point. They are what they are and they cannot change.

[rotemdan]

@DavidArno

I did not initially intend to suggest changing this behavior in the language specification. I'm aware this would be a breaking change. Introducing breaking changes seems to be something that mostly Microsoft team members can "dare" to propose, and they do: here is a list of breaking changes in C# 10.

I initially thought it was a compiler bug.

I also don't personally believe that had I personally suggested it during discussions for C# 8 it would make any difference. About two years ago I've donated an enormous amount of time and effort providing carefully thought-of suggestions and comments for the record design proposal and my suggestion were completely ignored by the design team (not a single comment).

Since then I have no interest in participating in language discussions. I only posted here because @CyrusNajmabadi suggested me to.

[koszeggy]

It changes the assigned value from 12341234123412341 to 12341234123412340. The original worked fine

Please note that switch statements and switch expressions are fundamentally different. A switch expression is just a syntactic sugar, which is equivalent to:

var s = "a";
object result =
    s == "a" ? 12341234123412341L
    : s == "b" ? 3.14
    : s == "c" ? true
    : throw new Exception("");

And as @CyrusNajmabadi has also mentioned, s == "a" ? 12341234123412341L : 3.14 has always been a double expression since C# 1.0.

In fact, adding the : s == "c" ? true 'case' like this used to be illegal until recently because it produced an error:

Conditional expression is not valid because a common type was not found between 'long' and 'target-typed conditional expression'.

so you had to fix it by explicitly casting one of the branches, for example: : s == "c" ? (object)true. The need of the explicit cast was often cumbersome, though one can admit it helped to avoid the confusion about the type of the result.

[bernd5]

I agree that this looks somehow strange.

But it has nothing todo with target type new.
The real issue is that there is an implicit conversion from long to double which might causes data loss.

See comment from spec:

Conversions from int, uint, long, or ulong to float and from long or ulong to double may cause a loss of precision, but will never cause a loss of magnitude. The other implicit numeric conversions never lose any information.

The exact rule how the type of a switch expression is determined:

The type of the switch_expression is the best common type of the expressions appearing to the right of the => tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted to that type. In addition, we add a new switch expression conversion, which is a predefined implicit conversion from a switch expression to every type T for which there exists an implicit conversion from each arm's expression to T.

(The second part allows the "bool arm")

Fixing is explained here: here

And these rules were designed with the mindset that implicit conversion dot not cause data loss...

[HaloFour]

Warning on a loss of precision on implicit conversion sounds like a good use case for an analyzer.

IIRC there's only a few cases of "target typing" in C#. Generally the expression and assignment are treated separately, so the switch expression needs to be evaluated to a specific type. Then the assignment statement needs to determine how to coerce the type of that expression into the target type for the assignment.

[bernd5]

Yes, exactly like you wrote.
@rotemdan if you use visual studio you can hover over the switch keyword and see the type of the whole expression:

[tannergooding]

Conversions from int, uint, long, or ulong to float and from long or ulong to double may cause a loss of precision, but will never cause a loss of magnitude. The other implicit numeric conversions never lose any information.

The wording of never a loss of magnitude is also a bit odd. @CyrusNajmabadi do you know what the intent of that wording is?

My assumption here would be that it is meant to mean that "any long converted to double will never have an absolute value that would compare as less than the original long". However, that's not true as IEEE floating-point has "round to even" behavior and so 9007199254740993UL rounds to 9007199254740992.0, this is a loss of magnitude.

[CyrusNajmabadi]

This does not seem like an issue of backwards compatibility,

This is definitely an issue of backwards compatibility now. We cannot change this without breaking a lot of code that depends on this behavior.

And we cannot break it without also then introducing a different form of inconsistency that would be likewise unfortunate.

So this isn't a case where a break is even arguable as strictly better. It's a case where it will improve some cases for some users a bit, but it will also degrade things for others by potentially more.

It is unlikely we would go that route without enormous evidence that the current state of a affairs is broken and otherwise unsalvageable. However, currently, that does not seem to be the case.

[CyrusNajmabadi]

I work on designing experimental languages that are much more forward-looking than this one. I'm interested in conception and big ideas, not nitpicking on small technical issues

That's awesome! I love hearing about different languages and the ideas and designs behind them. Is love to take more about what you work on if you're interested. We'd def love to also have that insights with our decisions :-)

Please reach out at any time on discord. It would be fascinating to learn more about your domain! And we can likely share a little more about our own criteria and the "technical issues" that affect us.

Thanks!

[CyrusNajmabadi]

In my own language I infer sum and literal types (e.g. integer | decimal, 10 | -15.5) whenever there are multiple choices or assignment paths (this includes conflicts between various numeric types).

That's very cool. Do you have a particular representation that you use for encoding things? What's the final size of one of these entities? Is there overhead on top of the largest individual entity you might be storing here?

[rotemdan]

I never requested anyone should even consider to "fix" this issue on the language level at all,

@rotemdan you did just that. Your op says:

Please consider sorting out your specifications to make them more predictable and useful for the programmer.

I didn't really know what to write. I mostly meant "for the future sake" I guess? Why would I expect a breaking change of this magnitude after 3 years of it being in the language?

We are discussing that very request...

--

Furthermore, I feel like this is a no win. You've complained before about people not engaging and responding when you raise concerns. Now you're pushing on us to not respond. This is another case where we're damned no matter what. If we do not engage you will say we ignore concerns. If we engage you will say that you don't want to converse with us.

I don't have a discord account / never used it. What I wrote is from past experience participating in CS/TS discussions (mostly TS, from around 2014 - 2017). I don't intend to push anyone not to respond, and I'll try to respond myself. I've spent the last 24 hours just commenting and couldn't really concentrate to get anything done. I just returned from a walk outside, even tried to mute notifications but it didn't seem to work, I'm still getting notification emails.

I also must say that I'm surprised you're taking this so seriously. I didn't expect to get much replies.

I find this issue very trivial, almost boring, that's why I described this as "bikeshedding" (maybe that wasn't the best wording though).

• First of all, in my own language integers are intended to be arbitrary-precision (though temporarily I use Int64), which removes even the option of casting them to decimals.
• Second, it's based on an entire programming style where asserting over the types of variants (unions, any, or even object) is used as control mechanism. In this style it is inconceivable that type information is not preserved when assigning to the variant since it is essential to determine the flow of the program.

That's why it would take me "5 seconds" to resolve an issue like this in my own language. It's a "no brainer" as you'd say.

I've been using the pattern in C# itself (where object acts as the variant type) as part of my compiler (the fact I chose C# as a language for the compiler should be a demonstration I appreciate the language - mostly for the huge engineering effort put to it and its tooling). I used switch expressions a lot (initially due to the analyzer recommending it for me), and the particular case where I encountered this issue is when I build the AST from the parse tree, where the minimum and maximum values of a range literal type (e.g. 5..infinity) may be parsed either as an integer or decimal value. I used the type information within object to store the original type the value contained.

Here's the exact original code (after the fix suggested here to cast to object so the strange behavior is avoided):

object ParseRangeLiteralEndpoint(SyntaxAnalysis.Node.Terminal terminalNode) =>
	terminalNode.Kind switch
	{
		"integerLiteral" => (object) long.Parse(terminalNode.Value),
		"decimalLiteral" => double.Parse(terminalNode.Value),
		"positiveInfinityLiteral" => Double.PositiveInfinity,
		"negativeInfinityLiteral" => Double.NegativeInfinity,

		_ => throw new Error("Unexpected range terminal node kind")
	};

[CyrusNajmabadi]

I also must say that I'm surprised you're taking this so seriously. I didn't expect to get much replies.

We strongly appreciate and like to engage with the community on feedback. You rose your concerns and we felt that that warranted full and complete transparency on our side as to the decision making that both went into it, and what we could potentially do about it now.

This also feels really hard to thread the needle. You previously complained about teams not engaging fully with community and their feedback. Now you seem to be surprised that we are trying to engage fully with you and your feedback :)

I didn't really know what to write. I mostly meant "for the future sake" I guess?

Sure. And our responses have been in the vein of our thoughts around htat. As i mentioned, given a fresh language (or a deeper willingness to break existing code), i think this would definitely be a design pivot we might consider. I don't think anyone has said your views make no sense or are inconsistent. Merely that we have to balance many concerns here in terms of what is possible for us, and that many decisions we make will ultimately always be suboptimal to some subset of our user base. We strongly feel like you deserve to get real answers and real explanations here, esp. since you took the time to share your thoughts and go into them in so much detail :)

I've spent the last 24 hours just commenting and couldn't really concentrate to get anything done.

I would recommend simply taking breaks and spending time on other stuff. This is just a language discussion forum. No need for it to be something that should negatively affect your happiness or health :( Take your time and work on thigns you prefer. If you feel like engaging more in teh future, we'll certainly be here and still happy to share our thoughts with you :)

I find this issue very trivial, almost boring, that's why I described this as "bikeshedding" (maybe that wasn't the best wording though).

Ok. But surely you can see that others may feel differently right? A core part of discussion is coming to understandings of how others feel :) For many of us, the concerns on things like "back compat", "consistency", etc. are deeply significant and critical to a full analysis and discussion of the topic. If that doesn't interest you that's completely fine. However, we have to frame the conversation with full transparency of all the points that are relevant to our product, and its past and future. In that regard, these aspects are exceptionally non-trivial :)

If you feel like we overthink this side of things, that's totally fine. Even internally every single LDM member has different weights and biases on all these different aspects of the design. However, our goal is to work together to best understand all those concerns and then try to navigate through it to find a final design we can collectively feel resulted in the best outcome overall (even if particular aspects are suboptimal compared to others).

This is honestly the primary challenge (and, dare i say, fun) of the process. There are rarely "perfect" answers that are just "superior" on every dimension we're weighing. Instead, there are many options, all with different pros/cons and different weights per person. Balancing that all out is the process of design :)

Cheers!

[CyrusNajmabadi]

First of all, in my own language integers are intended to be arbitrary-precision (though temporarily I use Int64), which removes even the option of casting them to decimals.

Cool! I hope our future languages can have this concept, as well as still providing easy access to the data types that are the intrinsic, perf oriented ones, that CPUs excel at :)

Second, it's based on an entire programming style where asserting over the types of variants (unions, any, or even object) is used as control mechanism. In this style it is inconceivable that type information is not preserved when assigning to the variant since it is essential to determine the flow of the program.

That's awesome. I really respect that design and think it has many attractive elements to it. I fully see how our historical behavior here around these data types is not only suboptimal for you, but downright hostile. Given a chance to do it all over again, we might really rethink these legacy behaviors (and how they've intertwined themselves deep throughout the langauge). In the meantime though, i think analyzers are a great way for people to say: "yup... here's historical behavior that probably needs preservation, but which i really don't like". Esp. in areas where we're more relaxed, its' a way for a user to say: "no, i'm willing to have to be much more stringent, even if it means existing code will stop compiling".

Analyzers help us bridge that gap between the deep majority that has shown they highly favor compat and stability, with the minority that really is willing to accept costlier upgrades if they feel that the breaks end up helping them avoid things they foudn problematic to begin with.

Again, as per a previous thread, we're super happy to help work with you on creating those analyzers.

I don't have a discord account / never used it.

That's fine. It's totally up to you. I'll just say we have a thriving community in discord with thousands of community members engaging in many different forums for many different purposes. Writing analyzers is one purpose and discord is where you likely can get the most help and advice on how to write this the best way possible. You're also most likely to find people there (myself included) who can just directly work with you on this sort of thing.

Cheers!

[CyrusNajmabadi]

The design team decided they would prefer to preserve this behavior

In a strong sense yes. :-)

Preservation of behavior is a very important tenet for us. As is reusing concepts throughout the language for consistency.

Switch expressions, for example, aren't meant to replace existing constructs. They're meant to compliment them. If they were meant to replace (say because we considered the prior constructs to be a mistake), then we'd use that opportunity to introduce new and different semantics.

However, that's not what happened here. Rather we still feel the existing constructs are good and have semantics we think are acceptable. So we wanted switch expressions to fit into that family, not create its own new family :-)

BTW, for history, at one point we considered making this construct just look like a ternary expression (?:), just allowing an arbitrary number of cases. Had we gone that route and had different behavior for 3+ arms vs 2, it would have been hugely confusing :-)

[CyrusNajmabadi]

It was not an obvious decision at all.

Sure. But we discussed this sort of thing at length and ultimately made a decision we felt was appropriate balancing this concern along with a whole host of others.

We even considered things like not allowing Target typing to work in a case like this.

Ultimately though, we felt the best benefit to users around be to be consistent with existing expression forms, while also allowing Target typing. We recognized this sort of situation could arise, but we believed overall it would, in whole, be the best outcome for the language and community.

[CyrusNajmabadi]

Introducing breaking changes seems to be something that mostly Microsoft team members can "dare" to propose, and they do: here is a list of breaking changes in C# 10.

This is certainly true. However, the bar for breaking changes in extremely high.

First off, there has to be a belief that very few people will be hot by the change. Second, there has to be a belief that almost no code hit by the break was likely to be correct before.

This is not the case here. This week likely hit many people, and we will likely get more reports about working code breaking vs the single report here that the behavior we chose is undesirable.

We have to balance things out and make sure that the cure is not worse than the disease. :-)

[CyrusNajmabadi]

which also forces Int64 values to be implicitly cast to Double

Double vs long is another case with enormous history in the language and a huge amount of code that depends on that. However, that case was never even part of my argument.

I was simply stating that conditionals allow for Best common type first, over a Target type. And in any where a conversion could happen (including all the cases without data loss) that has been the behavior of the language.

We do this 'best common type' concept in many places. It's a core idea the language has been built on, and which we think of as positively. It would be extremely strange to not use it given our history and it would likely feel like we were bifurcating things :-/

[CyrusNajmabadi]

and that outsiders (non team-members) have practically no say.

First, this is not true. We've changed the language several times based on user feedback. We're doing this right now in fact because of user feedback around initializers in structs. And we're going to take a breaking change there (again based on user feedback). There we feel though that the time period is short enough that we can change things without impacting too many people, and because the change won't give you different behavior, it will simply make a highly suspect case illegal, and the user can add code to get either behavior they want.

These kinds of boards exist mostly as a facade to provide outsiders with the illusion of participation

What does "illusion of participation" mean? We are literally discussing the matter and several Language designers are here sharing their thoughts about this as well as giving the history of this topic, the pros/cons that were discussed, why we settled on what we did, and what would be necessary to get a change here.

How is that either an illusion or not participation?

or as an "outlet" for them to express their opinions to mostly deaf ears, or maybe to get some free ideas and contributions for Microsoft.

As you can see, this did not fall upon deaf ears. The designers here are both listening and giving a ton of information to help explain how we see and process this feedback as well as how we determine how it could go forward.

Nothing has been ignored here. It's simply that this is not a trivial thing that can be changed. Nor is it something universally (or even broadly) considered to be a mistake.

That's why this is a discussion. So that people from all backgrounds and beliefs can Converse on the topic and both listen and share what they think. Thanks!