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

Design idea: string interpolation #2005

Open
jonmeow opened this issue Aug 12, 2022 · 14 comments
Open

Design idea: string interpolation #2005

jonmeow opened this issue Aug 12, 2022 · 14 comments
Assignees
Labels
design idea An issue recording a specific language design idea that folks can potentially pick up. long term Issues expected to take over 90 days to resolve.

Comments

@jonmeow
Copy link
Contributor

jonmeow commented Aug 12, 2022

Per discussion on #1811, there's interest in string interpolation but it's not an area that's been closely examined. This is an area where a proposal would be helpful.

https://en.wikipedia.org/wiki/String_interpolation gives some information and provides some cross-language examples which may be helpful for proposal background and thinking about options. It's important to consider the syntax that multiple languages are looking at.

In Rust, I think https://www.rustnote.com/blog/format_strings.html and rust-lang/rfcs#2795 may provide some interesting ideas and alternatives to think about. Note though that while Print is using meta-programming in Rust, the leads have expressed interest in exploring non-meta-programming-based solutions first.

As a possible data source, it may be worth poking at a few sourcegraph searches (such as this one) to see what developers are doing today.

@jonmeow jonmeow added good first issue Possibly a good first issue for newcomers design idea An issue recording a specific language design idea that folks can potentially pick up. labels Aug 12, 2022
@OlaFosheimGrostad
Copy link

OlaFosheimGrostad commented Aug 12, 2022

I would like to give this a go.

@Niikelion
Copy link

Javascript have pretty basic, but easy to understand and use string interpolation(template strings): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals . C# syntax, while being more complex(it incorporates option to specify data formats) is also worth considering in my opinion: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated .
If you want to discuss syntax and/or possible ways to approach implementation I will be more than happy to help.

@OlaFosheimGrostad
Copy link

C# syntax, while being more complex(it incorporates option to specify data formats) is also worth considering in my opinion: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated . If you want to discuss syntax and/or possible ways to approach implementation I will be more than happy to help.

Yes, I am thinking that maybe $"…" is a good solution. I am trying to map out various use scenarios and various string-buffer-targets in order to get good performance. High level languages create many temporary strings, and it would be nice if we could avoid that for some use cases.

I don't know which discord channel we can use for interpolated strings yet, but feel free to share ideas in this issue, I read it regularly.

@OlaFosheimGrostad
Copy link

OlaFosheimGrostad commented Aug 15, 2022

We might end up needing to support C 20 std::formatter, so it is possible that our hands are tied as far as number formatting goes. On the upside, the C 20 formatting spec is pretty non-controversial, a lot like Python for instance.

@Niikelion
Copy link

I don't think that we are constrained by std::formatter syntax in designing string interpolation, but I agree that it is a good idea to get some inspiration from it. Format in interpolation could be specified like this: $"{pi: 10f}" and would roughly translate to std::format("{:10f}", pi);. I think that we can skip all cases that require passing additional arguments to format, like std::format(":{}.{}f",pi, 10, 5); and hope that value : value is not a valid value expression in Carbon.

@OlaFosheimGrostad
Copy link

OlaFosheimGrostad commented Aug 16, 2022

I don't think that we are constrained by std::formatter syntax in designing string interpolation

We might be if we want to support formatting of C types, see chrono for instance: https://en.cppreference.com/w/cpp/chrono/local_t/formatter

(Constrained in the sense that we can do a rewrite to what C formatter expects.)

@Tomttth
Copy link

Tomttth commented Aug 16, 2022

I was going through wikipedia and found this groovy feature interesting:

final n = 52
def sentence = "n is ${n%2 == 0 ? "even" : "odd"}"
println sentence

It would be good if we can compute the value in the string literal itself.

we can fine tune in this way for carbon:

$"n%2==0?'even':'odd'"

@OlaFosheimGrostad
Copy link

OlaFosheimGrostad commented Aug 16, 2022

$"n%2==0?'even':'odd'"

Carbon appears to be using if cond then value else value for conditional expressions, so one option might be to write this as:

let sentence:auto = $"n is { if n%2 == 0 then "even" else "odd" }";

@OlaFosheimGrostad
Copy link

We now have a channel on Discord, feel free to share your thoughts here:

https://discord.com/channels/655572317891461132/1009125434929201172

@geoffromer
Copy link
Contributor

That Groovy example talks about developers in sexist and ageist terms, and we don't do that here. I know it's copied verbatim from Wikipedia, but that kind of language can still be hurtful when it's inside quotation marks. I've replaced it with a more innocuous example in the comments above (and also fixed the formatting, because the $s were confusing GitHub).

@torlarse
Copy link

This is what I see when clicking the link to Discord from this thread. Am I doing it wrong?

image

@jonmeow
Copy link
Contributor Author

jonmeow commented Aug 21, 2022

@torlarse The link works fine for me. It's #string-interpolation on Discord. Note, if there are any Discord-specific followups, please use a separate discussion to let this issue stay focused.

@Tomttth

This comment was marked as off-topic.

@jonmeow jonmeow removed the good first issue Possibly a good first issue for newcomers label Sep 9, 2022
@jonmeow jonmeow mentioned this issue Sep 9, 2022
@github-actions
Copy link

github-actions bot commented Dec 9, 2022

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time.
This issue is labeled inactive because the last activity was over 90 days ago.

@github-actions github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Dec 9, 2022
@josh11b josh11b added long term Issues expected to take over 90 days to resolve. design idea An issue recording a specific language design idea that folks can potentially pick up. and removed design idea An issue recording a specific language design idea that folks can potentially pick up. inactive Issues and PRs which have been inactive for at least 90 days. labels Dec 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design idea An issue recording a specific language design idea that folks can potentially pick up. long term Issues expected to take over 90 days to resolve.
Projects
None yet
Development

No branches or pull requests

7 participants