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

custom character literal macros? #26305

Closed
stevengj opened this issue Mar 2, 2018 · 2 comments
Closed

custom character literal macros? #26305

stevengj opened this issue Mar 2, 2018 · 2 comments
Labels
breaking This change will break code parser Language parsing and surface syntax speculative Whether the change will be implemented is speculative

Comments

@stevengj
Copy link
Member

stevengj commented Mar 2, 2018

I wonder if we want to support character literal macros analogous to custom string macros, e.g. b'x' as a synonym for UInt8('x').

This would be a breaking change because b'x' is currently parsed as b' * x':

julia> b = 3; x = 7
7

julia> b'x'
21

This occurred to me in connection with #26286, e.g. if you want to have custom literals for a new character type. Also, there is a lot of code that prints individual ASCII bytes to an io stream. To do this efficiently while still supporting streams in different encodings, you'd ideally want an ASCIIChar type, and it would be convenient to write this as a'x'. Of course, we could define a custom string literal for this, like a"x", but it would be confusing if that were defined to produce a character.

Not a necessary feature by any means, just wanted to throw it out there since it would be a breaking change.

@stevengj stevengj added speculative Whether the change will be implemented is speculative breaking This change will break code parser Language parsing and surface syntax labels Mar 2, 2018
@JeffBezanson
Copy link
Sponsor Member

I think it's better to use string macros for this than to sacrifice x'y'.

@stevengj
Copy link
Member Author

stevengj commented Mar 3, 2018

Okay, I figured it wouldn't be popular.

@stevengj stevengj closed this as completed Mar 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code parser Language parsing and surface syntax speculative Whether the change will be implemented is speculative
Projects
None yet
Development

No branches or pull requests

2 participants