how does const declaration set to itself work

Question

This is the declaration for PositiveInfinity in Double.

/// <summary>
/// Represents positive infinity. This field is constant.
/// </summary>
/// <filterpriority>1</filterpriority>
public const double PositiveInfinity = double.PositiveInfinity;

This looks like a cycle that wouldn't pass the compiler... why is it declared this way & how does this work?

The primitive declarations actually tie into the CLR primitive types. IIRC, special sauce goes into the compilation (and the DLLs/types themselves) that let's them use the CLR types vs the `System.Double` types you see in decompiled DLL info. — Chris Sinclair, Jun 01 '13 at 14:39
I found a few related questions that essentially explain this better: http://stackoverflow.com/questions/16693421/when-is-a-double-not-a-double, http://stackoverflow.com/questions/4751885/how-are-the-primitive-types-defined-non-recursively, http://stackoverflow.com/questions/16113850/if-int32-is-just-an-alias-for-int-how-can-the-int32-class-use-an-int — Chris Sinclair, Jun 01 '13 at 14:43
@ChrisSinclair. Thanks! Why not turn your comments into an answer I can accept? Cheers — Berryl, Jun 01 '13 at 14:47
Also, did you get at this code via a decompiler? Often times those provide misleading/confusing results like this for the primitive types. For example, they can list `public const double NaN = double.NaN;` but in reality its real source code is `public const double NaN = (double)0.0 / (double)0.0;` — Chris Sinclair, Jun 01 '13 at 14:48
@EricLippert. That's from using resharper's decompiler (dot.net peek, I think) — Berryl, Jun 01 '13 at 14:49
@Berryl Eh, I'm not confident enough to do that. I have a very _fuzzy_ idea of how the primitive types link/interact with the CLR; not enough to put in an answer I think for other people to get real use from (I'd probably get something slightly off base). Besides, the linked answers I think do a bit better job of that anyway. — Chris Sinclair, Jun 01 '13 at 14:50
@Berryl: Chris is correct: Resharper does not always give you back code that will compile. It makes a best guess and in this case it gets it wrong. Your question presupposes a falsehood: that is *not* how the constant field is declared and if it were declared like that, it would be rejected by the compiler. If you want to see how the field is actually declared, download the reference sources. http://referencesource.microsoft.com/ — Eric Lippert, Jun 01 '13 at 14:51
@ChrisSinclair. Eric Lippert thinks you got the right answer too... not a bad confidence booster — Berryl, Jun 01 '13 at 14:55

score 14 · Accepted Answer · answered Jun 01 '13 at 15:00

This is the declaration for PositiveInfinity in Double.

No, it is not.

This is a portion of the decompilation of the Double struct provided by Resharper.

That's better.

This looks like a cycle that wouldn't pass the compiler.

That's because it is a cycle that would not pass the compiler.

Why does Resharper's decompiler produce code that doesn't compile?

My guess is that it's a bug. You'll have to ask the Resharper team for a definitive answer.

Likely they have a heuristic that says to put Double.PositiveInfinity in anywhere that a positive infinity constant appears; this is perhaps the one place where that's wrong. So that's an easy bug to write.

What does the real declaration look like?

I haven't got reference sources on my home computer, but my guess is that the real declaration is:

public const double PositiveInfinity = 1.0 / 0.0;

Where can I get the reference sources, so I don't have to rely on an unreliable decompiler?

http://referencesource.microsoft.com

I was just looking up in the reference to provide the source too. You got it right; verbatim it is: `public const double PositiveInfinity = (double)1.0 / (double)(0.0);` — Chris Sinclair, Jun 01 '13 at 15:01
@Eric Lippert. source is also conveniently available [online here](http://www.dotnetframework.org/Search.aspx) — Berryl, Jun 05 '13 at 14:36

how does const declaration set to itself work

1 Answers1