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

FLIP 288: Simple String Interpolation #289

Merged
merged 4 commits into from
Oct 30, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 91 additions & 0 deletions cadence/20240923-simple-string-interpolation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
---
status: draft
flip: 288
authors: Raymond Zhang ([email protected])
sponsor: Supun Setunga ([email protected])
updated: 2024-09-23
---

# FLIP 288: Simple String Interpolation

## Objective

This FLIP proposes adding support for simple string interpolation limited to identifiers only (no support for full expressions).

## Motivation

Currently Cadence has no support for string interpolation. It is convenient for developers to be able to inline variables in strings as opposed to the current solution of applying `concat` repeatedly.

In general many languages support string interpolation for readability and ease-of-use.

## User Benefit

Developers can avoid repeatedly using `concat` to generate strings which will simplify code and readability.
turbolent marked this conversation as resolved.
Show resolved Hide resolved

## Design Proposal

The main constraint is backward compatibility, existing Cadence 1.0 code cannot be affected. The proposed solution follows the syntax of swift as below:
turbolent marked this conversation as resolved.
Show resolved Hide resolved
turbolent marked this conversation as resolved.
Show resolved Hide resolved

```swift
"Variable = \(someVar)"
```

This change is backwards compatible because `\(` is not currently a valid escape character.

For this initial proposal there will be several limitations on `someVar`:
- `someVar` will only be variable references with ability to be extended to expressions in the future
turbolent marked this conversation as resolved.
Show resolved Hide resolved
- `someVar` must support the built-in function `toString()` meaning it must be either a String, Number, Address or Character.
turbolent marked this conversation as resolved.
Show resolved Hide resolved

This is still useful for the first iteration since there are easy workarounds for these limitations such as extracting expressions into local variables.

### Drawbacks

None.
SupunS marked this conversation as resolved.
Show resolved Hide resolved
Comment on lines +43 to +45

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: One little drawback I see is that \( is a bit of an uncommon escape sequence for string interpolation. I haven't seen a language that uses that. I don't think this really matters, but I do feel like it's a bit easier to guess the correct syntax or scan the code if using a common syntax (which I'm not sure is possible given backward compatibility constraints as mentioned).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somewhat agree, it is not the most common syntax. However it is used by Swift and as you mentioned syntax such as "${}" does run into backward compatibility issues.


### Alternatives Considered

String interpolation is preferred over a formatting function (such as `printf`) for the following reasons:

- Formatting is error prone (e.g. passing a `String` to `%d`)
turbolent marked this conversation as resolved.
Show resolved Hide resolved
- There are many languages which moved from traditional formatting to string interpolation (e.g. Python)

### Performance Implications

None, non-interpolated strings should not be affected.
turbolent marked this conversation as resolved.
Show resolved Hide resolved

### Dependencies

None.

### Engineering Impact

This change should be simple to implement.

### Best Practices

It may be preferred to use string interpolation over concat once implemented.

### Compatibility

Proposed changes are backwards compatible.

### User Impact

This is a feature addition, no impact.

## Related Issues

https://github.com/onflow/cadence/issues/3579

## Prior Art

- https://docs.swift.org/swift-book/documentation/the-swift-programming-language/stringsandcharacters/#String-Interpolation
- https://docs.python.org/3/tutorial/inputoutput.html#formatted-string-literals
turbolent marked this conversation as resolved.
Show resolved Hide resolved

## Questions and Discussion

Feel free to discuss on the PR.

## Implementation

A POC is available at https://github.com/onflow/cadence/pull/3585.