~icefox/garnetc#28: 
Sometimes we can't know the types of numbers

Basically, if we have the expression

let x Bool = 3 == 4

then we have no way to decide what concrete integer type the 3 and 4 should be. You have to annotate one or the other, even though it's basically meaningless. In this situation Rust assumes that they are I32, which is Fine but still honestly feels like something of a hack. Is there any better way of doing it?

Status
RESOLVED CLOSED
Submitter
~icefox
Assigned to
No-one
Submitted
1 year, 2 days ago
Updated
a month ago
Labels
T-BUG

~icefox referenced this from #23 1 year, 2 days ago

~akavel 8 months ago

IIRC, in Go consts are considered "infinite"/arbitrary precision until required to be "down"-cast to some concrete precision. And const expressions operating on consts are IIRC by default also operating on those infinite/arbitrary precision consts (i.e. the compiler uses BigInt under the hood in those cases, I believe). Not sure if that applies to all cases that you meant here, but just sayin'.

See e.g.: https://go.dev/blog/constants and https://go.dev/ref/spec#Constants

~icefox 8 months ago

Yeah I think Zig does something similar. We already have an "unknown integer" type, which is what the typechecker starts off assigning to 3 and for in 3 == 4, but all instances of PrimType::UnknownInt have to go away by the time typechecking is finished.

I think the key question is, if we allow an "infinite"/arbitrary-precision integer to exist, when the expression 3 == 4 hits the backend, how much memory does it allocate to store the values 3 and 4? In this particular case it's quite easy to say that the backend will always constant-fold the expression into false and so you don't need to care in practice, but will that always be true no matter what? If not, we have to define some kind of language semantics around it...

~icefox a month ago

Currently we simply do not allow these cases to typecheck, which to me is the Obvious Easy Solution. See commit 058cd107ef12.

~icefox REPORTED CLOSED a month ago

Register here or Log in to comment, or comment via email.