Elements of AnyStr are difficult to handle
              
              #1446
            
            Replies: 1 comment 2 replies
-
| I don't think there's a very compelling case for  I don't think it's too big of an ask having to write the latter, sure it's less readable and it's not as type safe for the internals, but there's a way to get most of the way back to the first example by adding a  The more general case of  | 
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Consider the following code (which assumes a symbol called
AnyStrElemis available):(Even using this hypothetical facility (
AnyStrElem), there's some awkwardness: I'm aware of no interface tostrandbyteswhich can be used to construct anAnyStrfrom a sequence ofAnyStrElems; handling this accounts for about half the length ofencode_value().)Of course, we don't have
AnyStrElem, so instead we're forced to write something like this:The latter is far less readable, quite a bit less safe (more
casts,type: ignores, etc.), and almost twice as long by character count.1 (We could have skippedvalue_to_digit()anddigit_to_value()in the first version, referencingself._fwdandself._revdirectly, making the contrast in length even greater.)Proposal One:
AnyStrElemThe simplest fix would be to add
AnyStrElemas a special case, as used in the first example above.Proposal Two:
TypeOfIntroduce an operator which sets a
TypeAliasto the type of some expression.This would read something like this:
This would be more legible (and less polluting of the namespace) with a corresponding
ValueOfTypeoperator:Discussion
Thanks for taking the time to consider this problem!
Footnotes
about 65% longer after stripping imports, comments, docstrings, common indentation, and converting spaces to tabs ↩
Beta Was this translation helpful? Give feedback.
All reactions