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 |
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 ↩
All reactions