It's a tricky case because they do provide the `big""` macros for literals, and mention in BigFloat's docs that:

      BigFloat(x::AbstractString) is identical to parse. This is provided for convenience since decimal literals are converted to
      Float64 when parsed, so BigFloat(2.1) may not yield what you expect.

      ...
      Examples
      ≡≡≡≡≡≡≡≡≡≡

      julia> BigFloat(2.1) # 2.1 here is a Float64
      2.100000000000000088817841970012523233890533447265625
      

However, saying RTFM is not a solution, especially for not-too-frequent parts of the language like BigFloats. It's still a trap many people are going to fall for.

The solution here is a good linter though, not adding more work to the already overstressed compiler. It comes back to the issue of Julia needing more mature, easy-to-work-with tooling, that could say "hey, this is technically allowed, but you probably didn't mean this".

The argument isn't silently treated as a double, it is explicitly and loudly treated as a double, because it is a literal double.

And this is not an advantage to the designer exclusively, it is very much an advantage for the end user that the treatment is explicit, consistent and predictable, instead of 'magically' reinterpreting the meaning of literals based on guessing the intent of the user.

Basically, you seem to be saying that when passing x to BigFloat, x should not be treated as the value x, but as some nearby value that might be the one the caller intended (based on some rounding logic perhaps?) Or are you perhaps saying that

    x = 1e-300
    y = BigFloat(x)

should be different from

    y = BigFloat(1e-300)

? In other words, completely discarding referential transparency?

I think the argument here is that parsing of the string '1e-300' maybe should be context dependent. In this case, 1e-300 is being parsed as a double, and then forwarded to the function. Maybe it could be parsed as a bigfloat whenever it is an argument of a function expecting a bigfloat.

Yes, I got that argument, and that is exactly what I was arguing against. You cannot and should not parse the literal double `1e-300` differently dependent on which function it is later passed to. This is what `big"1e-300"` or `BigFloat("1e-300")` is for, where the BigFloat constructor parses the string.

Julia does this for exponentiation, i.e. a literal exponent is parsef differently that exponentiation by a variable.

I think it was a mistake. Invariably, a new user discovers the discrepancy and is thoroughly confused. Let's not repeat the same mistake with big nums.

I don't think this has anything to do with whether 1e-300 and 10.0^-300 is parsed differently (and perhaps that is a mistake). The poster seems to want to parse 1e-300 directly as a BigFloat in the call `BigFloat(1e-300)`, because of the function it is passed to.

Yeah what I mean is - we already have "magic parsing" with literal_pow, and it's confusing and unnecessary. It was a mistake. We should not make the same mistake when parsing float literals