chore(docs): correction of data type of loop index

[TAdev0]

Description

Problem*

Resolves #3315

Summary*

This PR replaces u64 for field in the description of the loop index i.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[kevaundray]

We changed this to be u64 -- do you see something different when you run Noir programs?

[TAdev0]

@kevaundray yes, even with 0.19.2, i get this error :

error: Comparisons are invalid on Field types. Try casting the operands to a sized integer type first

if i do something like this :

    for i in 0..8 {
        for j in 0..8 {                   
             if  (i + j < 8) {...}

[TAdev0]

@kevaundray oh i see, 8 is of type field, this code works like this :
if (i+j < 8 as u64) {...}

my bad!

[TAdev0]

well, actually, the behaviour is odd, this compiles as well :

  if  (i as u64 + j as u64 < 8) {...}

It seems one of the two operands needs to be converted to a uint

[kevaundray]

I think thats possibly a separate issue -- I would have expected 8 to be automatically casted to a u64 without the explicit cast

[TAdev0]

It seems that 8 is automatically casted to a u64 only if we explicitly declare i and j as u64 in the comparison.

[kevaundray]

can you open an issue for this?

[TAdev0]

Sure. I'll do it tomorrow in the morning as soon as i am available.
Should i close this PR as it is finally irrelevant ?

[jfecher]

This may be an ordering issue with two type constraints. IIRC i and j are not actually u64s, they just default to u64 if no other type is specified. The same is the case for the literal 8, although it defaults to Field instead.

The important part is that internally we have a TypeVariableKind::IntegerOrField (for 8) but not a corresponding kind for just integer / u64. The delayed_type_check hack is used instead which is why this defaults to Field and is not caught. The fix for this is to remove the hack and have a dedicated type variable kind - so yes this should be a separate issue. This PR can be closed.

[jfecher]

Closing this - it is part of a separate issue.