Rename CanBeState<T> to be more concise

[dphfox]

The CanBeState<T> type is ever-present in modern Fusion code, as Fusion has moved in the direction of making all dynamic code generic over state-object-ness, accepting constants in places where previously we only ever allowed state objects.

This type, while self-descriptive, is unfortunately verbose. A slimmer name might be a good idea. In addition, as we further blur the line between constants and state objects, it's very possible that the distinction between the two becomes an implementation detail that's not relevant to users, so decoupling the name of this type from state objects could be sensible.

I'm personally partial to Dynamic<T> - it ties in nicely with the idea that Fusion code is about annotating what parts of your program are expected to handle dynamically changing values, versus which parts of your program cannot handle dynamically changing values.

Another idea I considered is NonConstant<T>, but I'm less partial to this because it implies that you can't ever provide a constant value, which is misleading.

[dphfox]

Usable<T> could be a good proposal, too.

[Sluethen]

Verbose isnt always bad thing. In this case its clear as day what CanBeState means, while something like Dynamic doesn't get across immediately CanBeState isnt even that long

[dphfox]

Verbose isnt always bad thing. In this case its clear as day what CanBeState means, while something like Dynamic doesn't get across immediately CanBeState isnt even that long

This is the single most used type definition across all Fusion code bases I've ever worked with, and likely it's going to increase over time, so every little bit counts here. I've found this type name clutters up a lot of property list definitions especially, so I'm interested in optimising that use case.

[dphfox]

Perhaps a name like MayChange<T> helps retain some of the original clarity while still moving away from assuming knowledge of state objects.

[dphfox]

After some further discussion in the community Discord channel, we considered a few more names:

• Describes<T>
• Contains<T>
• Becomes<T>
• Into<T>
• UsedAs<T>
• As<T>
• StateOf<T>
• StateOr<T>
• Or<T>
• Maybe<T>
• a bunch of other rejected ideas

After much discussion we settled on a few strong ideas:

• StateOr<T> - essentially a more concise CanBeState<T>, but still leans heavily on state terminology which goes against the goal of pushing state objects further into implementation detail territory
• Describes<T> - conveys a lot of meaning, but can be a little bit clunky in large code blocks
• Becomes<T> - same issue as above
• Contains<T> - strongly leading name; seems to suggest the existence of a structure
• UsedAs<T> - very concise and nicely encapsulates the way people think about this type (don't care what it is, only what comes out of use()), but would be nicer to consolidate down to one succinct word
• As<T> - almost as strong as above, avoids its main issue but loses out a bit on clarity - is is clear that new users know what it means?

Right now, myself and the people who I talked to agree that As<T> seems to have the strongest combination of traits, but I think it is still good to collect further thoughts on this.

[dphfox]

The symmetry of type Use = <T>(UsedAs<T>) -> T is quite nice.

[dphfox]

After talking with some more groups, common opinion seems to be that the clarity of UsedAs<T> outweighs the conciseness of As<T>, so (at least for the time being) I think that it would be the option that achieves most of the goals set out above while retaining enough clarity to be understood by a wide audience.