Skip to content

String Interpolation #968

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

Closed
BraedonWooding opened this issue Apr 30, 2018 · 4 comments
Closed

String Interpolation #968

BraedonWooding opened this issue Apr 30, 2018 · 4 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.

Comments

@BraedonWooding
Copy link
Contributor

BraedonWooding commented Apr 30, 2018

I couldn't find any issue that matched this, so I felt this should be created.

Most languages have a nicer way to do a format then having to do something like format("{}", myObj), often they either take the 'Swift' route and do something like "\{myObj}" with the \{being existent in all strings; I personally don't like this as it does seem to do 'stuff' behind your back without you asking for it.

Whereas the 'C#' way which is something like $"{MyObj}", requires a symbol to designate that it is interpolated, I feel that this way is nicer in terms of usability and demonstrates clearly if a string should be interpolated you can write '{' by double writing it like {{ kinda like escaping it; we could also allow escaping it via the typical escape keyword \{ but that may be too similar to the first method to confuse people.

The third way is I guess more inline with the fact that Zig doesn't really use symbols for things like this and uses 'words' (i.e. transition from % to try) so I guess it would be something like fmt "{MyObj}" which would just translate to format("{}", MyObj).

'fmt' is just a name I chose to demonstrate the idea it is an implementation detail so probably not something to 'argue' about, more focus on the idea.

Why have this?

It helps when you have long format strings as you can easily prevent weird bugs of putting things in wrong orders (though those bugs are typically caught easily). I don't have too many reasons for why they really are 'needed' so I wouldn't say that this is a necessity but it's one of those things I find that most people just go 'huh that's nice', kinda like how the 'for' loop in zig is not necessary but it just makes things nice.

On the other hand the negative of having it is 'bloating the language' (something I disagree that this would do but I can understand this view), you could also argue it is doing stuff 'behind' your back, but I would argue it is not doing anymore than what something like 'try' is using.

😄

@Hejsil
Copy link
Contributor

Hejsil commented Apr 30, 2018

There are a few problems that need to be addressed before this could ever become a thing:

  1. Is the fact that Zig does not rely on its standard library (except for std.build and std.special(which is not exposed to the user through std)). To this, people might just say "Well, the compiler could just generate fmt in buildin.zig or something", but I'd like to point out that builtin.zig contains no functions (even after Metaprogramming - @typeInfo [DONE] #951) and Zig doesn't have any features that generate a lot of code (unless generating code is the purpose of the feature, aka inline loops).
  2. How do we actually store the string? In Zig, we pass allocators around and handle allocation errors, so we have to be able to do that. You're fmt keyword could be used like this: try fmt<&some_allocator> "{myObj}". But then I have to ask, is it really any better than: try fmt.allocPrint(&some_allocator, "{}", myObj)?

Zig tends to avoid adding "fluffy feel good once in a while features" because, as you said, it wants to be simple and less bloated than most alternatives. I'd say, that if features only reason to exists is "Eeeeh, why not." then I don't really think it is worth adding. Though, I will say that for loops are too nice to let go :) They do also communicate the indent "I'm looping over memory", which while loops might not always do if the condition is complicated.

There is, however, a few things hidden in this proposal that should probably be discussed (either here or have their own proposals):

  • Maybe we should allow this: "{2} {1}", obj1, obj2. Here we can refer to which argument we want to use in the format string. This does not really solve the problem that people might get the order wrong though.
  • Should there be a way to use different format strings at runtime? A use case for this is when printing in many different languages. This is the one use case where printf outshines Zig's formatting.
  • We should have a way of providing custom formatters for types. This has been discussed in the IRC, but I don't think there is a proposal yet.

@Hejsil
Copy link
Contributor

Hejsil commented Apr 30, 2018

One other note! Did not think about only allowing this at comptime. Here we don't have to worry about allocation failure and all that stuff, and we already have ++ and **. I think this feature have a higher chance of being a comptime only thing, but I still don't really think it's need.

@BraedonWooding
Copy link
Contributor Author

BraedonWooding commented May 2, 2018

Been meaning to reply, just forgot sorry. I actually completely agree, and I don't really see this in 'Zig' the more I think about it; however I still felt it was worth creating the issue just incase others had opinions :). Also means its a place to drive people who ask this in the future.

On your other points, I agree that referring to objects is quite nice; printing different format strings at runtime is extremely important too, though I think that is probably the place for a library to come in? Since it is quite a niche place, however I may be wrong.

And yes it was a complete comptime feature so that's why I didn't mention allocators :). But I actually don't think it's a need or even a want really, I think Zig is nice enough already with printing things.

@Hejsil Hejsil added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label May 2, 2018
@andrewrk
Copy link
Member

andrewrk commented May 3, 2018

👍

@andrewrk andrewrk closed this as completed May 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

3 participants