Change validation to reject stream<char> (for now) #607
+12
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Right now, because
elem_size(char) == 4, if you usestream<char>you're effectively using UTF-32 which is not great. Now that's also the case forlist<char>but everyone usesstringinstead which is encoded/decoded usingstring-encoding, which is one ofutf8,utf16orlatin1+utf16. Symmetrically, we could add astring-streamand indeed there's currently a bullet in Concurrency.md#TODO to add such a thing.However, in retrospect,
list<char>should've probably been special-cased in the ABI lift/lower rules to usestring-encodingso thatstringis pure sugar forlist<char>(and if we ever actually needed UTF-32, it could be a newstring-encoding=utf32... but probably not). Once we add an opt-incanonoptfor #383, we can piggyback other pending breaking ABI changes (e.g., bumpingMAX_FLAT_RESULTSto be greater than1), so we could actually fix this (or not; it bears discussion in the future). But in the meantime, for the upcoming 0.3.0 release, given that if you usestream<char>you're going to have a bad time and we don't necessarily want to addstring-stream, the conservative thing to do seems to be to just rejectstream<char>at validation time and then we can figure out what we want later w/o breaking anyone.