FLIP 293: StructStringer interface

[RZhang05]

Flip #293 working towards onflow/cadence#3579.

[SupunS]

[Just cross-referencing] There were some concerns raised before, over having a user-defined toString functions for composites:

• Add string formatting function  cadence#3579 (comment)
• Add string formatting function  cadence#3579 (comment)

[turbolent]

Nice! Adding a built-in interface, implementing it for built-in types that support it, and allowing Cadence developers to implement the interface for their types, makes a lot of sense 👍

[turbolent]

This might be infeasible, given that not all values of AnyStruct are stringable.

[SupunS]

👍 from me

[bluesign]

I had some concerns in the beginning but after thinking a bit more on it, this is great 👍

• Is 'string' also 'Stringer'?
• should some standard library functions change 'string' parameters to 'Stringer'?

[RZhang05]

Is 'string' also 'Stringer'?

Yes it would be, this is the case in Swift with their CustomStringConvertible.

[turbolent]

should some standard library functions change 'string' parameters to 'Stringer'?

That should not be necessary and would just complicate and slow down the functions, because they would all have to first call toString on the argument, even though in most cases it would just be a string.

This is also uncommon in the standard library or in "user code" of other languages. For example, Go's standard library functions work with strings as inputs, not fmt.Stringer.

[turbolent]

One thing I realized in the discussion above is that we should probably clarify what the result of the toString function should be. Not all, but quite a few other languages make the distinction between a "human-readable representation", and a "debug representation". The former is used for display purposes to show to the user using the application, while the latter is meant to be helpful for the developer of the application.

For example

• In Python there are the __str__ and __repr__ functions
• In Swift there are the CustomStringConvertible and CustomDebugStringConvertible interfaces, with description and debugDescription properties
• In Rust there are the Display and Debug traits

It might be good to clarify this in the proposal and note that the purpose of the proposed stringer interface is the former, providing a "human-readable representation".

I'm noting this, because currently we actually have the latter, the "debug representation", which makes sense for the log debugging function. For example, log("foo") logs "foo" (note the quotes), not foo (similar to how Swift "foo".debugDescription produces "foo").

When we're implementing this proposal we need to make sure to implement a new set of string functions and use it for the built-in types. Concretely, e.g. interpreter.StringValue.String() currently quotes. We might want to rename this e.g. DebugString, Representation, etc.

[turbolent]

We discussed this FLIP in yesterdays working group call. Attendees liked the proposal and there were no concerns, so this FLIP is accepted 🎉

As always, thank you everyone for reviewing proposals and providing valuable feedback 🙏