there is a full, its name is widen

[Sacha0]

This pull request sketches the second option described in #24147 / provides the functionality discussed in #23270. (After some thought, that generic function has (in an abstract sense) the semantics of widen. So for now this pull request extends widen instead of introducing a new exported name.) Please see #24147 for more. Best!

[mbauman]

I don't quite think this name fits.

If x is a type, return a "larger" type (for numeric types, this will be a type with at least as much range and precision as the argument, and usually more). Otherwise x is converted to widen(typeof(x)).

Am I correct in the fact that the defining characteristic of this operation is that we want to ensure that the returned array is completely mutable? Or maybe both dense and completely mutable? If either of those are case, then I think I'd prefer to defer the design here to the broader trait scheme discussion for 1.x. I'm not entirely sure what the answer will be, but it'd be nice to leave the door open here. I think that means not giving this operation a name for now.

[Sacha0]

Am I correct in the fact that the defining characteristic of this operation is that we want to ensure that the returned array is completely mutable? Or maybe both dense and completely mutable? If either of those are case,

Neither of those is the case :). The semantics of this operation are: Given a wrapped array type (the "narrower" type), return the type of the parent of a copy of an instance of that type (the "wider" type). Given a non-wrapped array type, return that array type. Given an instance of an array type, call the operation on the type of that instance and then convert the instance to the resulting type. In approximate terms, strip a wrapping layer.

The name does not matter to me :). (The analogy is quite loose, but the type / instance behavior is roughly the same: widen the type, convert instances to the widened type of that instance.)

I think I'd prefer to defer the design here to the broader trait scheme discussion for 1.x. I'm not entirely sure what the answer will be, but it'd be nice to leave the door open here. I think that means not giving this operation a name for now.

As I express in #24147, I share those sentiments:

Thirteen calls to copy!(similar(parent(A)), A) in a specific context don't alone seem worth exporting a new generic name from Base (nor worth extending an existing Base export in a major way). The generic function in #23270/#24148 may find other uses, but playing with those other uses / carefully vetting behavior prior to introducing such functionality seems wise. And we can introduce such functionality after 1.0, but we can't change or remove it in the 1.x series if we inject it now.

Best!

[JeffBezanson]

I also think widen doesn't really fit. It would kind of make sense for e.g. widen of Bidiagonal to give Tridiagonal, but (1) this is hard to define uniquely, and (2) this isn't what the function does :)

[Sacha0]

Cheers, a different name then if we move forward with these semantics :). The more important question here / in #24147 is whether we need an operation with these or similar semantics at this time (and so far common sentiment seems to favor alternatives in #24147). Best!

[Sacha0]

Closing in favor of #24147. Thanks all!