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

Add string formatting function #3579

Closed
bluesign opened this issue Sep 11, 2024 · 4 comments · Fixed by #3660
Closed

Add string formatting function #3579

bluesign opened this issue Sep 11, 2024 · 4 comments · Fixed by #3660

Comments

@bluesign
Copy link
Contributor

Issue to be solved

context: https://discord.com/channels/613813861610684416/1162086721471647874/1283181721562517607

It would be nice to have some basic string formatting.

Suggested Solution

No response

@SupunS
Copy link
Member

SupunS commented Sep 16, 2024

Based on the discord discussion, this feature can be have two parts:

  • Introduce a Stringer interface.
    • Make all string-convertible types are subtypes of this newly added interface
    • See the existing HashableStruct type for inspiration.
  • Support string templates, where formatting can be inlined in the string-literal itself.

@jribbink
Copy link
Contributor

jribbink commented Oct 2, 2024

Just wanted to chime in here, I ran into a similar need tinkering on something a while back, but maybe with some more specific constraints.

I was looking to deterministically produce human-readable String representations of AnyStruct for the use-case of signing arbitrary Cadence values (something functionally equivalent to the output of log right now would be sufficient). Unfortunately, I couldn't really find a way to verify a signature for an arbitrary AnyStruct value on-chain right now.

The reason I'm commenting here is because depending on the implementation of the Stringer interface, it may or may not be suitable for this use-case. If the Stringer implementation is native to the language, then they could be safely used in this example. However, if developers were responsible for implementating the Stringer interface on structs, it would not be reliably safe, nor ergronomic for this use-case.

I am not saying that the Stringer interface has to be the solution to the problem I faced, however, I think it's important to point out the potential value of allowing developers to safely stringify structs which they may not control the implementation of.

(Not sure where this comment belongs, the linked FLIP seems to be limited to discussion around string interpolation)

@bluesign
Copy link
Contributor Author

bluesign commented Oct 3, 2024

If the Stringer implementation is native to the language, then they could be safely used in this example

@jribbink I agree user defined Stringer is dangerous (I raised some concerns on this before), but also a quick note, in general for your use case, native Stringer can be also dangerous.

In general you need 3 properties; deterministic, uniqueness and immutable ( more like crypto hashing ) I think output of ‘log’ lacks some.

@SupunS
Copy link
Member

SupunS commented Oct 22, 2024

Thanks @jribbink and @bluesign for the feedback! Given the concerns, we opened a FLIP for the Stringer interface specifically: onflow/flips#294 to discuss these concerns further and find a solution that works. We can also discuss in one of the upcoming working groups as well.

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

Successfully merging a pull request may close this issue.

4 participants