Target Typed Number Literals

[SilentSin]

Along the same lines as target typed new, Switch Expressions, and Name Lookup, what about target typed literals:

float value = 0.1;// Target is a float, so the literal is a float.
var value = 0.1f + 0.1;// The second one is a double (to avoid a breaking change).
float value = 0.1f + 0.1;// This time it's a float (because it won't compile as a double).
float value = someOtherFloat + 0.1;// Same.
var value = 0.1;// Default to double.
Debug.Log(0.1);// Default to double (assuming Log(object)).
MethodThatTakesAFloat(0.1);// Float because it can't be a double.

In general terms, when I write 0.1 I don't usually care whether it's a float or double. It's a floating point value so it's going to be imprecise either way and any calculations it's used in can vary in precision depending on the hardware, so I already need to acknowledge the possibility of floating point error and inconsistencies. So I propose allowing 0.1 to mean that I don't really care which type it uses; still default to double to avoid breaking old code, but if it won't compile then see if it can do so using the target type.

In more technical terms, if an unmarked numeric literal (0.1 rather than 0.1f or 0.1d) would not be valid as its default type (0.1 defaults to double), then you can treat it as if it had the suffix for the target type (or if it is an expression, then this applies to any numeric literals in that expression). So since someFloat = 0.1 isn't allowed, treat it as someFloat = 0.1f instead. And since someDecimal = 0.1 isn't allowed, treat it as someDecimal = 0.1M.

Benefits

• Numbers are much cleaner and easier to read without sticking letters next to them.
• Easier to refactor. Change between float and double without needing to add/remove the f.
• Easier to learn. No need to know the difference between float and double to understand why you need to drop f bombs everywhere. Decimals can be read by normal people instead of decimal value = 0.1M looking like it could be referring to Meters or Millions.
• Faster to type. You save one whole character.
• This idea already exists for some numeric types since you can already do float value = someFloat + 1 and byte value = 1.

[canton7]

var value = 0.1f + 0.1;// The second one is a float since it's being added to a float.

This is a breaking change.

[SilentSin]

You're right. I've edited the OP.

[canton7]

So the only change is to allow float f = 1.0; and float value = 0.1f + 0.1;?

[SilentSin]

Yes, though it would most often be used as float value = someOtherFloat + 0.1 or MethodThatTakesAFloat(0.1) so I'll put those in the OP too.

[canton7]

float f = 0.1; is potentially confusing, because e.g. 1e100 is a valid double literal everywhere except float f = 1e100;, where it would have to generate a compiler error.

For float value = someOtherFloat + 0.1, there's the potential for confusion: does this mean float value = (float)(someOtherFloat + 0.1), or does it mean float value = someOtherFloat + 0.1f?

MethodThatTakesAFloat(0.1) is also potentially confusing: what if you have:

void Method(float f);
void Method(double d);

If you write Method(0.1) you'd have to pick the double overload. So you're introducing new rules into method overload resolution - an area which is famous for being overly-complicated already!

At the moment, floating-point literals are nice and clear: if it ends with f, it's a float; otherwise it's a double. I worry that this is introducing a lot of potential for confusion, for the sake of saving an f here and there.

[SilentSin]

float f = 0.1; is potentially confusing, because e.g. 1e100 is a valid double literal everywhere except float f = 1e100;, where it would have to generate a compiler error.

True, but that's already a compiler error so it's hardly a big deal. It would just change from "can't implicitly convert literal" to "constant is out of range" which is more immediately useful. Currently you would see the former error, stick an f on it, and then see the latter instead of just getting the latter error upfront.

For float value = someOtherFloat + 0.1, there's the potential for confusion: does this mean float value = (float)(someOtherFloat + 0.1), or does it mean float value = someOtherFloat + 0.1f?

If I wrote that, the latter would 100% be what I intended it to do. I'm not specifically telling it to use doubles anywhere and it's faster without the cast. If you actually intend a double literal you can always use 0.1d, but that's far less likely if you are already working with two floats.

If you write Method(0.1) you'd have to pick the double overload. So you're introducing new rules into method overload resolution - an area which is famous for being overly-complicated already!

What new rules? The rule I'm proposing would address overload resolution in the same way as it addresses everything else: if it can't be a double, try a float (and the same for int -> long). In this case it can be a double, so it's a double.

But the vast majority of systems I know of only deal with one type or the other. For me in Unity that's usually floats and I'd love to be able to use position.x += 0.1 or if (time > 0.5).

At the moment, floating-point literals are nice and clear: if it ends with f, it's a float; otherwise it's a double. I worry that this is introducing a lot of potential for confuson, for the sake of saving an f here and there.

I disagree. Which one do you think Method(1) calls? I would have guessed double since it can hold every int, but it actually calls the float overload. That's already part of the language even though it's both more confusing and more significant because you could lose the precision of a strongly defined integer value rather than a floating point value which already has inconsistencies between hardware (meaning you already have to account for floating point error).

[YairHalberstadt]

@canton7
We already have this for ints and shorts.

short x = 1; and int x = 100000000 compiles, but short x = (int)1; and short x = 100000000 doesn't.

I can't see any reason why this should be different, but then again I don't know if this is worth the effort.

[canton7]

If I wrote that, the latter would 100% be what I intended it to do.

The thing is, that isn't necessarily true for everyone. I know that 0.1 is a double literal. If I write someFloat + 0.1, I know that I'm adding a float to a double, and the result is a double. I would not expect target-typing anything to change that.

What new rules?

See section 7.5.3.5 of the spec.

[canton7]

@YairHalberstadt that's not quite the same as this proposal: short i = 1; short x = i + 3 is a compiler error, whereas OP is proposing that float f = 0.1; float x = f + 0.1 would not be a compiler error, and would instead be implicitly the same as float x = f + 0.1f;

If this were just a proposal to allow float f = 0.1 then that's a different matter: that's much more limited in scope, and the compiler could implicitly turn 0.1 into 0.1f and take things from there (including emitting the messages it currently emits if a float literal is outside the range of a float). I could support that proposal, although I don't see much point in it, since you can just add the f suffix.

However, the proposal is about finding all double literals in an expression and implicitly turning them into float literals if the target type of the expression is a float (or could be a float, if a suitable method overload, etc, is found).

[SilentSin]

Where do you draw the line though? Is float f = 1.0000000001 a compiler error? That's another double that can't be converted to a float without loss of precision.

That seems obvious; you draw the line where it can't be done without loss of precision for the same reason you can't use 1e100f. It's a literal and the compiler outright knows it can't have that value, so you get an error.

The thing is, that isn't necessarily true for everyone. I know that 0.1 is a double literal. If I write someFloat + 0.1, I know that I'm adding a float to a double, and the result is a double. I would not expect target-typing anything to change that.

But how meaningful is that distinction in practice? The result is not much of a double since it is being assigned immediately to a float. My understanding is that the precision of internal calculations like that already varies based on the hardware so the exact values are anyone's guess until it actually gets assigned to your float so you can use the result, at which point it's obviously not a double.

If you write someFloat + 0.1 and know it's a double then put float value = in front of it, you obviously don't want it to be a double anymore.

However, the proposal is about finding all double literals in an expression and implicitly turning them into float literals if the target type of the expression is a float

Not quite. I'm proposing implicitly turning them into floats if they can't be doubles, which seems like an important difference because it would only come into play if the old way fails.

[gafter]

That seems obvious; you draw the line where it can't be done without loss of precision

In other words, 0.1 would not convert to float, because doing so loses precision? (Really, it does)

[ronnygunawan]

This will be very useful for decimals.

decimal price = 9.99; // currently not allowed

[SilentSin]

In other words, 0.1 would not convert to float, because doing so loses precision? (Really, it does)

Convert to float if it can't be a double and if sticking f on the end would actually be a valid float.

0.1f is valid so 0.1 can fall back to float.

1.0000000001f is not so it can't fall back to float.

1.0000000001M is valid so it can fall back to decimal.

[canton7]

Note that float f = 1.0000000001f is valid C# (it just silently loses precision)

[canton7]

How about a simpler alternative: allowing an implicit conversion from a double literal to a float literal? That gets you almost all of the way there, and it's quite a bit simpler.

• float f = 0.1; works
• var value = 0.1f + 0.1; is still a double
• float value = 0.1f + 0.1; does not compile, because it uses double operator +(double, double)
• float value = someOtherFloat + 0.1; does not compile, because it uses double operator +(double, double)
• MethodThatTakesObject(0.1) still a double
• MethodThatTakesFloat(0.1) now it's a float
• floatVariable += 0.1 is now allowed (because the handling of op= in the spec is weird, see Section 7.12.2.

It differs from your suggestion in that float value = 0.1f + 0.1 doesn't compile (but really, should it?), and likewise float value = otherFloat + 0.1 (which is perhaps more of an issue).

To be more specific, if the implicit conversion from a double literal to a float is chosen, then it is compiled as if it was a float literal, with all of the same (albeit tweaked) errors for e.g. 1e100.

[CyrusNajmabadi]

Then your statement seems pointless in the first place

Then feel free to ignore it. It was just me pointing out that we are extremely wary about code changing meaning.

[CyrusNajmabadi]

Note: this discussion doesn't seem to really be adding anything new. I've stated my position, and the information i'm looking for in order to potentially change it. You're welcome to provide new info (or not). Up to you :) gitter.im/dotnet/csharplang is also a good plae to discus this stuff and work with people as sounding boards to weigh out ideas and proposals. You may have more luck there refining things.

Good luck! :)

[SilentSin]

I didn't say: "omitting the type will not change the meaning"

It was just me pointing out that we are extremely wary about code changing meaning.

These two statements directly contradict each other. You made no mention of something being disallowed because it would change the meaning.

[CyrusNajmabadi]

These two statements directly contradict each other.

I literally did not say the first thing. You can see that right here:

I didn't say: "omitting the type will not change the meaning"

See the bolded part.

So you're stating there's a contradiction between something i said and something i did not say.

[CyrusNajmabadi]

Again, this discussion is not proving fruitful at all. I've stated my major objections to this proposal, both at a high level, and against the particular details (as best as i can distill them). I welcome any further contributions toward resolving those particular areas. I also would be very willing to continue the discussion in a more productive venue (like gitter.im/dotnet/roslyn, or https://discord.gg/csharp). I think that would work out a lot better. Thanks, and i hope to hear from you :)

[SilentSin]

I didn't say: "omitting the type will not change the meaning"

Yes.

Therefore omitting the type might or might not change the meaning.

Therefore your original statement that "you can omit the type when it would not change the meaning" can be added with " and you can also omit the type when it would change the meaning".

Therefore your original statement means nothing more than "you can omit the type", which does not say anything about your wariness to allow code to change meaning.

Which is a contradiction of your later statement that "It was just me pointing out that we are extremely wary about code changing meaning."

[CyrusNajmabadi]

Therefore omitting the type might or might not change the meaning.

Again, you are responding to a statmenet i didn't make. You claimed i was stating that. And all i'm saying is: i didn't state that.

Just because i didn't state it doesn't mean you then get to go make another claim about what i'm saying. All i actually claimed was:

you can omit the type when it would not change the meaning

the rest of tehse statements are ones of your own construction in response to statement that you claimed (incorrectly) that i said in the first place.

[CyrusNajmabadi]

IN other words:

Cyrus said: X
You said: Cyrus, you said Y.
Cyrus said: No, i didn't say Y. I said X.
You said: Well, if you didn't say Y, then that means you're saying Z. Therefor you're saying X and Z.
Cyrus said: No. I'm just stating X.

That's it. I made a claim. That claim is factual and is what i was trying ot state. You've made several other statements based on things i didn't actually say (and then made ever increasing statements on top of htat). These are all strawmen built on each other.

[SilentSin]

Your original statement "you can omit the type when it would not change the meaning" tells me what I can do. Not what I can't do. And not what you are wary of allowing people to do.

[SilentSin]

Your claim is factual, but useless. It doesn't demonstrate the point you were trying to make.

[CyrusNajmabadi]

Your original statement "you can omit the type when it would not change the meaning" tells me what I can do.

Yes. That was the point. It's very much the intention on how 'var' was designed.

[CyrusNajmabadi]

Your claim is factual, but useless. It doesn't demonstrate the point you were trying to make.

#2929 (comment)
#2929 (comment)

This is going in circles. And it's completely pointless and non helpful to the actual goal of pushing this proposal in some better direction.

I literally do not understand what you think this is buying your case. However the offer still stands to right the ship and get back to actually addressing the problems as i see it with the proposal, ideally in a location more conducive to that sort of conversation.

Cheers!

[SilentSin]

Yes. That was the point.

But according to your later statement, the point was somehow connected to you being wary of allowing the opposite of what you said.

[CyrusNajmabadi]

But according to your later statement, the point was somehow connected to you being wary of allowing the opposite of what you said.

#2929 (comment)

[CyrusNajmabadi]

The discussion about strawmen and claims of what were said are not furthering the language feature proposal at all.

For the purposes of putting this to bed: i retract 100% of every statement related to var. They have served only to distract you and get off of the valuable course of discussing this feature proposal. It benefits no one to continue on it. literally nothing fruitful is coming out of it. I cannot understand your insistence on keepign the discussion on it.

So, if it makes you willing to stop talking about it i will simply state either of the following if it works for you:

1. the entire 'var' discussion didn't happen. or
2. you are 100% right about the entire 'var' discussion. I agree with all your points on var and retract all my points.

Will that get us off of this and back onto the main topic again?