Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using u16 for array sizes #6245

Open
michaeljklein opened this issue Oct 8, 2024 · 2 comments
Open

Allow using u16 for array sizes #6245

michaeljklein opened this issue Oct 8, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@michaeljklein
Copy link
Contributor

Problem

It's currently impossible to use u16 for array sizes, but it would be useful for many arrays (u16::MAX == 65535)

#[test]
fn numeric_generic_u16_array_size() {
    let src = r#"
    fn len<let N: u32>(_arr: [Field; N]) -> u32 {
        N
    }

    pub fn foo<let N: u16>() -> u32 {
        let fields: [Field; N] = [0; N];
        len(fields)
    }
    "#;
    let errors = get_program_errors(src);
    assert_eq!(errors.len(), 2);
    assert!(matches!(
        errors[0].0,
        CompilationError::TypeError(TypeCheckError::TypeKindMismatch { .. }),
    ));
    assert!(matches!(
        errors[1].0,
        CompilationError::TypeError(TypeCheckError::TypeKindMismatch { .. }),
    ));
}

Happy Case

Support u16 as an array size (as above)

Workaround

Yes

Workaround Description

A u16 cast to a u32 can be used as the array size, but there's a performance impact

Additional Context

No response

Project Impact

Nice-to-have

Blocker Context

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

@michaeljklein michaeljklein added the enhancement New feature or request label Oct 8, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Oct 8, 2024
@jfecher
Copy link
Contributor

jfecher commented Oct 9, 2024

I don't see why we'd want to support u16 for array sizes as well. It seems like additional complexity for little to no gain

@michaeljklein
Copy link
Contributor Author

Pinging @TomAFrench for the original motivation

github-merge-queue bot pushed a commit that referenced this issue Oct 9, 2024
# Description

## Problem\*

* Need to check that type constants fit into their `Kind`'s
* The sizes of results from `op.function` and `evaluate_to_u32` are
unchecked

## Summary\*

Split out from #6094
- Some parts only work with its additional kind information
- Several follow up issues, including:
  * #6247
  * #6245
  * #6238

## Additional Context

TODO:
- [x] Add this test and/or similar execution tests unless we already
have a similar one (sanity-check that global `Field` arithmetic works
past `u32::MAX`)

```noir
// 2^32 + 1
global A: Field = 4294967297;
global B: Field = 4294967297;
global C: Field = A + B;

fn main() {
    // 2 * (2^32 + 1)
    assert(C == 8589934594);

    let mut leading_zeroes = 0;
    let mut stop = false;
    let bits: [u1; 64] = C.to_be_bits();
    for i in 0..64 {
        if (bits[i] == 0) & !stop {
            leading_zeroes += 1;
        } else {
            stop = true;
        }
    }
    let size = 64 - leading_zeroes;

    // 8589934594 has 34 bits
    assert(size == 34);
}
```

## Documentation\*

Check one:
- [x] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.

# PR Checklist\*

- [x] I have tested the changes locally.
- [x] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.

---------

Co-authored-by: Tom French <[email protected]>
Co-authored-by: Maxim Vezenov <[email protected]>
Co-authored-by: jfecher <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants