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

Should we allow even more operations on strings? #1306

Open
vlstill opened this issue Sep 9, 2024 · 1 comment
Open

Should we allow even more operations on strings? #1306

vlstill opened this issue Sep 9, 2024 · 1 comment

Comments

@vlstill
Copy link
Contributor

vlstill commented Sep 9, 2024

This follows on #1297. It is also connected to p4lang/p4c#4837. Currently strings can only be literals and the string type can only be used to declare extern arguments. With #1297, the concatenation of strings will be allowed. I wonder if we should allow even more operations, turning strings into more "standard" types, although existing still only at compile time (like int!).

Some things that could be allowed:

  • String constant declaration (not variables, just constants const string foo = "bar"). Essentially this just gives P4 life to something that can be now done using preprocessor.
  • Comparison for equality and inequality (==, !=).
  • Lexicographical ordering (<, <=, >=, >) -- here I am not sure if there is a good use case for this and it comes with its own caveats (e.g. the byte-wise lexicographic ordering is different from e.g. UTF-8 lexicographic ordering which depends on local). So we might defer this to later.
  • String slices (string[start:end]) -- again, the use case is not clear to me and it might be wise to wait for it.

The first two seem very safe to me.

@vlstill vlstill changed the title Should we allow even more operations on strings Should we allow even more operations on strings? Sep 9, 2024
@jonathan-dilorenzo
Copy link
Collaborator

I would generally like the first one.

If we have a real use case for 2 or 3, I suppose I could be convinced, but I suspect enums are better for anything that 2 might be used for and I have trouble imagining where I'd care to use 3.

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

No branches or pull requests

2 participants