Transform an array into a buffer via Array.buffer.

[matthewhammer]

Creates a buffer from an array.

[q-uint]

Yes. 💯

[ggreif]

Are the type parameters needed?

[matthewhammer]

Hmm, I'm not sure. I copied the code (including the type parameters) from the prior test and adapted it. Will check.

[matthewhammer]

Looks like the type arguments are indeed required:

arrayTest.mo:222.5-222.31: type error [M0098], cannot implicitly instantiate function of type
  <A>[A] -> Buffer<A>
to argument of type
  [Nat]
because implicit instantiation of type parameter A is under-constrained with
  Nat  <:  A  <:  Any
where
  Nat  =/=  Any
so that explicit type instantiation is required

https://github.com/dfinity/motoko-base/runs/6870423809?check_suite_focus=true#step:8:373

[crusso]

The type instantiation is necessary because buffer is invariant (right?) so there is no principal choice.

[crusso]

I'd add a doc comment and maybe consider adding a more general 'fromIter' method too, especially if we already have 'toIter'.

[ggreif]

Looks fine to me!

Maybe change the PR title (type signature?)

[crusso]

Hmm, shouldn't that be called toBuffer (or maybe even preferably Buffer.fromArray to avoid coupling Array.mo to Buffer.mo) for consistency with other conversions?

And a (trivial) doc comment would be useful.

It's not too late to change since we haven't released this yet.

[crusso]

This PR is also related to #368.

[rossberg]

Drive-by: agreeing with Claudio, this should be Buffer.fromArray.

[matthewhammer]

Drive-by: agreeing with Claudio, this should be Buffer.fromArray.

To be clear, we are still talking about a module function within module Buffer, not a class method within class Buffer, right?

If so, fine. Otherwise, this suggestion doesn't make sense to me.

Update:

Nevermind. I am looking at the other PR, and I think it's clear we are all talking about a module member, not a class member.

#389 is ready for review.