You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allowing literal bytes and strings to be interpreted as both string and bytes types introduces additional complexity in type checking. It becomes particularly burdensome within a for loop:
foriin ["foo", b'\x66\x6f\x6f', b"foo"]:
# what is i?
Forcing the use of b"" for bytes, "" for strings makes code more readable and simplifies type checking.
Specification
Within the AST these types are differentiated as Str and Bytes. Implementing this will simply require more selective node class checks when parsing.
Backwards Compatibility
This is a breaking change, but updating contracts to use the new syntax will not be difficult.
Simple Summary
Bytes literals should require prepending with
b
, string literals should require not prepending withb
.As an example, the following contract currently compiles. I believe that every statement within
bad
should raise anInvalidLiteral
exception:Motivation
Allowing literal bytes and strings to be interpreted as both
string
andbytes
types introduces additional complexity in type checking. It becomes particularly burdensome within a for loop:Forcing the use of
b""
for bytes,""
for strings makes code more readable and simplifies type checking.Specification
Within the AST these types are differentiated as
Str
andBytes
. Implementing this will simply require more selective node class checks when parsing.Backwards Compatibility
This is a breaking change, but updating contracts to use the new syntax will not be difficult.
Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: