Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VIP: Remove type ambiguity in bytes and string literals #1876

Closed
iamdefinitelyahuman opened this issue Mar 7, 2020 · 1 comment
Closed
Labels
VIP: Approved VIP Approved

Comments

@iamdefinitelyahuman
Copy link
Contributor

Simple Summary

Bytes literals should require prepending with b, string literals should require not prepending with b.

As an example, the following contract currently compiles. I believe that every statement within bad should raise an InvalidLiteral exception:

@public
def good():
    a: bytes[3] = b'\x66\x6f\x6f'
    b: bytes[3] = b"foo"
    c: string[3] = "foo"

@public
def bad():
    a: bytes[3] = "foo"
    b: string[3] = b'\x66\x6f\x6f'
    c: string[3] = b"foo"

Motivation

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:

for i in ["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.

Copyright

Copyright and related rights waived via CC0

@fubuloubu fubuloubu added the VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting label Mar 7, 2020
@fubuloubu fubuloubu mentioned this issue Mar 16, 2020
8 tasks
@fubuloubu fubuloubu added VIP: Approved VIP Approved and removed VIP: Discussion Used to denote VIPs and more complex issues that are waiting discussion in a meeting labels Mar 16, 2020
@fubuloubu fubuloubu added this to the v0.2 Release milestone Jun 21, 2020
@iamdefinitelyahuman
Copy link
Contributor Author

Closed in #2029

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
VIP: Approved VIP Approved
Projects
None yet
Development

No branches or pull requests

2 participants