I was writing a new version of a fixed-size array manifesto, and I got to the flatten-into-buffer functions:

```
func withFlattening<T: [... ; some Any], R>(of: T, body: (UnsafeBufferPointer<T.Element>) throws -> R) rethrows -> R
```

Then I finally realized that all the earlier parts of the report use FSA existentials another way:

```
let intArray: [3 ; Int] = [1, 2, 3]
let doubleArray: [2, 2 ; Double] = [1.0, 2.0, 3.0, 4.0]
var numericArray: [... ; some Numeric] = intArray
//...
numericArray = doubleArray
```

I was using a FSA existential as a variable's type instead of just a generic constraint. This second use is that "generalized existential" feature I've read about here, right? We currently don't have it. (We can't make a `Numeric`

variable, let alone have it store `Int`

and `Double`

values at different times.)

Which brings up my problem. If we don't have generalized existentials now, then I probably shouldn't introduce a version of them in this manifesto. What if we add them later, but they have incompatibilities with the FSA ones? It would be better if I left them out, then when/if generalized existentials are added overall, everything would be consistent.

But some of the ideas already assume I can use FSA existentials as returnable types:

```
func extents<T: [... ; some Any]>(of a: T) -> [_ ; Int]
```

What would this return in a world where generalized existential values couldn't be returned?

```
func extents<T: [... ; some Any]>(of a: T) -> [#extentCountOf(T) ; Int]
```

could work, assuming we can't create constructs where the number of dimensions in `T`

would only be known at run-time. Also, I think without FSA generalized existentials, we would have to design a `AnyFSA<Element>`

type that works like `AnySequence`

, `AnyHashable`

, *etc.*

Or I could just go ahead and design generalized existentials for FSAs, and maybe we can later design any-type generalized existentials off my work. (There would still be consistency in this route.)