This thought came up while thinking on how fixed-sized arrays from my last proposal could be implemented.
A flexibly-sized type is:
- A fixed-sized array with at least one extent deferred until run-time
- A fixed-sized array that uses a flexibly-sized element type, even if the top-level array uses only compile-time extents
- A tuple that has at least one member of a flexibly-sized type.
Said types can be used for:
- top-level objects (code-block locals, globals, type-level stored properties)
- function parameters
- stored properties for
class
es
They cannot be used for:
- function returns
- stored properties for
struct
s - computed properties
- as part (or all) of an
enum
case's payload
So, what's supposed to happen when a struct
with a stored property based off a generic parameter gets a flexibly-sized type:
struct MyStruct<T> {
var hello: T
}
var world: MyStruct<[_ ; Int]> // I guess this chokes?
We would have to either just let the user take their chances, or maybe allow some sort of protocol to distinguish flexibly-sized types from conventional ones so designers can ban flexibly-sized types from constructs that would choke on them.
Maybe they could be named like:
AnyFlexible
AnySizeLocked
But, if you think about it, inflexible types can be treated as flexibly-sized types, but not the other way. In other words, inflexible type are subtypes of flexibly-sized types. So either:
- Make
Any
for both flexibly-sized and inflexible types, and addAnySizeLocked
for inflexible types - Make
Any
for inflexible types and addAnyFlexible
for flexibly-sized types.
I'm leaning towards the second. This breaks Any
being the universal protocol (in favor of AnyFlexible
), but being able to plug-in types into generic parameters that will end up choking in use in code is worse. Flexibly-sized type are coming in second, so using Any
for inflexible types keeps backwards source compatibility. Note that the default for unadorned generic parameters would still be Any
; AnyFlexible
always has to explicitly listed, even though it's higher up the protocol hierarchy.
Would this be the right decision?