Lack of immediate access to GenericArray to view associated functions and trait impls leads to confusion and annoyance.

Inizia esaminando come aes-gcm e aes-gcm-siv espongono Nonce e come viene utilizzato GenericArray, quindi leggi la discussione dell’issue per conoscere la direzione concordata per l’API. Il lavoro è completato quando i maintainer scelgono e documentano un approccio —riesportare GenericArray, aggiungere un wrapper o adottare un altro design— affrontando la compatibilità e la documentazione rivolta agli utenti.

It's understandable that aes-gcm and aes-gcm-siv use generic_array's GenericArray's for the Nonce type. What's less understandable though is why this is left an opaque type and not either a wrapper with its own documentation of its methods custom to the uses of ges-gcm* or that GenericArray is not re-exported both for convenience as well as documentation. As a new user, I was really confused by the fact that I could not access the documentation for the underlying type to see what associated functions/methods it supports or even how to get one besides converting from a slice (as is demonstrated by the top-level crate documentation). Not everyone knows the generic_array crate and knows what GenericArray is and I had to look through the source to find the implementations of what I thought were a private type but turned out to be an import that is used on the front end by the user despite not only not being re-exported but there being no mention in the top-level crate documentation where this type comes from.

I would personally prefer turning Nonce into a newtype custom wrapper but I understand that this can be an issue due to the fact that it fundamentally introduces breaking changes.

The second best option is to simply re-export GenericArray. After all, aes-gcm-siv re-exports the entire aead crate just like aes-gcm which also re-exports aes in addition. I think this is by far the most uncontroversial option but the seemingly random re-export seems for some reason distasteful, I propose a third proposal:

This one is a compromise between the last two: create a new type called something like NonceWrapper that does exactly what I mentioned in the first proposal and then impl From for Nonce, unwrapping it. One could then have replace all instances of taking a Nonce type with impl Into. I can't see any breakage that would come of this but obviously it would still work even without the function refactors, just less convenient.

I would be willing to make a PR if and when a solution is agreed upon. I would love to hear others' thoughts.