Alessandro Coglio

@collinc97 Here are answers to your questions: 1. It sounds like @gluax's proposed approach should be compatible: all we need for the proofs are the ASTs before and after each...

Having command-line options to generate the proof files sounds good to me. I suggest `--proof` instead of `--prove` since we are not actually having the Leo compiler run/check the proofs,...

Note that Rust allows them but has a special handling of whitespace at the beginning of the lines after the first one (see link in message above). It seems best...

Based on today’s discussion with @d0cd: Related to this, we could also consider whether, instead of the `@inline` annotation, we could use an `inline` keyword instead. This property is more...

My vote is for Proposal 1 or 2, because they are symmetric w.r.t. little vs. big endian. But in all three cases, I think that an operation to reverse arrays...

As discussed offline and on Slack, the fastest way to provide this capability in an initial and usable form is probably via natively implemented global functions ``` to/from-bits/bytes-le/be() ``` in...

If I understand correctly, `leo add` would become essentially "redundant" given the new `leo install`. If that's the case, I vote for deprecating and then removing `leo add`. There was...

We should also look at the related https://github.com/AleoHQ/leo/issues/897. Then we can close both once we reach a decision.

This is also related to https://github.com/AleoHQ/leo/issues/1617, as line terminators are also whitespace, and we need to decide the exact role of carriage return.

I confirm my (bold?) vote in #897 to only allow line terminators and space (ASCII 32). No (horizontal or vertical) tabs, no form feeds, definitely no non-ASCII whitespace. Other than...