symbol! macro

[cinder mural]

I noticed we removed the symbol! macro at some point and started using Symbol::short instead. What was the motivation for that?

An unfortunate side-effect is it results in embedding the original strings into the .wasm file, as well as the code for generating the symbol, which at least last time we evaluated this was in the order of 60-100 bytes per use.

[deft wigeon]

this is surprising

[cinder mural]

The symbol! macro did some things to force/ensure that the conversion from the string into the Symbol occurred at compile time.

[deft wigeon]

I had some trouble migrating it to the new approach

[cinder mural]

While the Symbol::short is a const function, Rust prefers to evaluate functions at runtime, so it'll always end up as code in the final .wasm unless you do things to force it to be evaluated as a constant.

[cinder mural]

Could you elaborate?

[deft wigeon]

I think these probably were resolved, I don't recall exactly though

there were some changes in terms of what compile-time infallible conversions are allowed for symbol

I don't remember exactly really

I'm not opposed to a macro if it is strictly better than a function

let's just maybe name it symbol_short as to avoid confusion

(not every symbol can be produced by it)

[cinder mural]

We saved hundreds of bytes off simple example contracts when we introduced symbol!, so it'd be good to keep it if we can.

[opal olive]

i think you can just do b! and that will make a symbol from a string?

because you can put bytes into symbol

b!("mysymbolgoeshere") something like that. i was doing something like this to parse byte strings in my contract before i duno any idea how many hundreds of bytes it added to the wasm but

[deft wigeon]

yeah, there was really no intention for this to be less performant

[cinder mural]

I'll create an issue.

[opal olive]

so is there no alternative to the symbol! macro yet?

[deft wigeon]

Symbol::short was supposed to be it...

[cinder mural]

https://github.com/stellar/rs-soroban-sdk/issues/927

It'd be awesome if Rust let the function author to choose for the function to always be evaluated as const. We wouldn't have this problem then. We wouldn't need to use macros at all then.

[deft wigeon]

well, maybe for code generation only. IIUC the macro trick is to create a const, I wonder if that would work in a function as well

[bronze cosmos]

I guess the Rust compiler doesn't want to let the author be the decider on that one, but enforce the const context rule 🙂 @cinder mural

[cinder mural]

You're right. It has some good reasons too for that. Technically const functions could evaluate differently when executed in a const context than in a non-const context, because they are compiled to the host architecture, not the target architecture.

[opal olive]

oh well can i see an example for using symbol::short then? was the way i was doing it wrong? I was just doing something like let string: symbol = b!("my string")

i ended up not even using symbol and just storying bytes because well

the contract doesn't actually need to decode the string i was storing

[bronze cosmos]

I think its the other way around? compiled to target not host?

[cinder mural]

What is b!? TIL

[cinder mural]

Regularly functions are compiled to the target, e.g. the .wasm. The host is the machine doing the compiling, and const functions excecuted in a const context are compiled adn executed for the host because the host is the one compiling the code for the target.

[bronze cosmos]

same thing just if you're sure the symbol len is < 10 then Symbol::short("") -- short is a const fn

[opal olive]

was it b! it's a macro to turn a string into bytes

[bronze cosmos]

if longer just use Symbol::new(...)

[opal olive]

ohokay well since Symbol is no longer 10 char limit can just Symbol("mybiglongstupiduselesstring") work

ah okay

thank you

this may come in handy

[bronze cosmos]

yeah sorry 8pm in here and been up since 4am

[opal olive]

and to think that at one point i actually was considering compiling strkey into my contract to decode strings

sounds like now i can just use symbols as strings if it's necesary

[bronze cosmos]

there's actually SymbolShort and Symbol now 🙂 the former max 9chars, the latter max 32 chars... its not like we actually have a regular String supported 😆

[opal olive]

hmm 32 characters, is there some significance to that? isn't that the length of a ed25519 key?

[bronze cosmos]

RTFM 😆

Symbols are used for the for symbolic identifiers, such as function names and user-defined structure field/enum variant names. That’s why these idenfiers have limited length.
While Symbols up to 32 characters long are allowed, Symbols that are 9 characters long or shorter are more efficient at runtime and also can be computed at compile time.

[opal olive]

ah yeah okay well stil this is great because it was a real hassle keeping all my function names 10 characters or less

[deft wigeon]

yeah, you shouldn't normally even need symbols beyond maybe some test fns (like the auth verification). you can use them for the keys of course, but it would be more readable to use the enums anyway. so for the most part this would affect the sdk

[bronze cosmos]

I honestly prefer using the DataKey::MyIdentifier than any String 🙂 so I agree to that

[opal olive]

yeah i forget what i was even doing the strings in a contract for. oh it was that chat app

[deft wigeon]

keep using strings, unless you build a chat where it's not possible to add spaces between words