(fluent.runtime) Add a FluentString type #84
Description
Arguments to FluentBundle.format may currently be instances of FluentType subclasses, or Uniode strings (str in Python 3). This mirrors the optimization from fluent.js, where primitive strings are treated as if they were FluentTypes thanks to supporting the same {toString, valueOf} interface. The same optimization was applied to the contents of TextElements and StringLiterals.
Would it make sense to drop this optimization? Perhaps the impact wouldn't be as significant in Python as it was in JS. And the benefit would be that the mental model of the resolver would become simpler, with one exception fewer.
@spookylukey What do you think?