Chained constructors give Expression type is ambiguous

[sirasistant]

Aim

Code like this used to compile:

use dep::aztec::{prelude::{NoteViewerOptions, PrivateSet}};
use dep::value_note::value_note::ValueNote;

fn main() -> pub Field {
    let set: PrivateSet<ValueNote> = PrivateSet::new(dep::std::unsafe::zeroed(), 0);
    let options = NoteViewerOptions::new().set_limit(1); // chained construction happening here
    let notes = set.view_notes(options);
    notes[0].unwrap_unchecked().value
}

With this in dependencies:

[dependencies]
aztec = { git = "https://github.com/AztecProtocol/aztec-packages", tag = "master", directory = "noir-projects/aztec-nr/aztec" }
value_note = { git = "https://github.com/AztecProtocol/aztec-packages", tag = "master", directory = "noir-projects/aztec-nr/value-note" }

Here is the code for NoteViewerOptions and private set:
https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/note/note_viewer_options.nr
https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/state_vars/private_set.nr

Expected Behavior

I think it should compile, since the generic of NoteViewerOptions should be resolved to the generic of set that is ValueNote

Bug

Instead it errors with Expression type is ambiguous

To Reproduce

Project Impact

Nice-to-have

Impact Context

No response

Workaround

Some

Workaround Description

Splitting it in two lines works:

use dep::aztec::{prelude::{NoteViewerOptions, PrivateSet}};
use dep::value_note::value_note::ValueNote;

fn main() -> pub Field {
    let set: PrivateSet<ValueNote> = PrivateSet::new(dep::std::unsafe::zeroed(), 0);
    let mut options = NoteViewerOptions::new();
    options = options.set_limit(1);
    let notes = set.view_notes(options);
    notes[0].unwrap_unchecked().value
}

Additional Context

No response

Installation Method

None

Nargo Version

No response

NoirJS Version

No response

Would you like to submit a PR for this Issue?

None

Support Needs

No response

[jfecher]

Can you give an example without the aztec dependency? I've tried encoding a version of NoteViewerOptions directly but it works as expected.

Instead it errors with Expression type is ambiguous

Where is the error? On the set_limit call, NoteViewerOptions::new, or somewhere else?

[jfecher]

Actually, I added a trait constraint like in the original and the error immediately appeared afterward:

fn main() -> pub Field {
    let _options = NoteViewerOptions::new().set_limit(1);
    0
}

struct NoteViewerOptions<Note, N> {
    limit: u32
}

impl<Note, N> NoteViewerOptions<Note, N> {
    pub fn new() -> NoteViewerOptions<Note, N> where Note: Default {
        NoteViewerOptions { limit: 0 }
    }

    pub fn set_limit(&mut self, limit: u32) -> Self {
        self.limit = limit;
        *self
    }
}

The error is on NoteViewerOptions::new which makes sense since the Note type is never constrained so it doesn't know which type to use to try to find Note: Default

I think an improvement for this error message is that it could try to mention the Note and N generics specifically as needing to be specified.

Rust gives a similar error message here but mentions the original Note and N names, and mentions the context of solving for a trait:

error[E0283]: type annotations needed for `NoteViewerOptions<Note, N>`
  --> foo.rs:2:9
   |
2  |     let _options = NoteViewerOptions::new().set_limit(1); // chained construction happening here
   |         ^^^^^^^^   ---------------------- type must be known at this point
   |
   = note: cannot satisfy `_: Default`
note: required by a bound in `NoteViewerOptions::<Note, N>::new`
  --> foo.rs:12:60
   |
12 |     pub fn new() -> NoteViewerOptions<Note, N> where Note: Default {
   |                                                            ^^^^^^^ required by this bound in `NoteViewerOptions::<Note, N>::new`
help: consider giving `_options` an explicit type, where the type for type parameter `Note` is specified
   |
2  |     let _options: NoteViewerOptions<Note, N> = NoteViewerOptions::new().set_limit(1); // chained construction happening here
   |                 ++++++++++++++++++++++++++++

[jfecher]

In your original example, I think it is occurring because let notes = set.view_notes(options); constrains the Note type to be ValueNote but does not constrain what N should be. I'm not sure why this wouldn't occur when a mutation is done. It may be related to the that type variable now being bound to another type variable.