Allow manipulating token strings

[skyrpex]

CDKTF allows manipulating token strings with the cdktf package by using the Fn.* methods (eg, let apiDomain = cdktf.Fn.trimprefix(api.url, "http://");).

These manipulations can be performed in Wing, and they work when deploying to tf-aws, but these tokens don't get resolved in the sim target.

You can reproduce it with the following program:

npm i winglang cdktf constructs

main.w:

bring cloud;
bring "cdktf" as cdktf;

let api = new cloud.Api();

let apiURL = api.url;
let apiDomain = cdktf.Fn.trimprefix(api.url, "http://");

log("apiURL = ${apiURL}"); // ${root/Default/cloud.Api#attrs.url}
log("apiDomain = ${apiDomain}"); // ${TfToken[TOKEN.0]}
new cloud.Service(inflight () => {
    log("apiURL = ${apiURL}"); // http://127.0.0.1:49401
    log("apiDomain = ${apiDomain}"); // ${TfToken[TOKEN.0]}
});

The thing is:

• Do we want to support cdktf's token manipulation?
• Otherwise, should we provide our own?

[skorfmann]

I think it's a general issue in the simulator, see https://github.com/winglang/wing/issues/2719 Once that's resolved, the issues described here should resolved as well.

[ekeren]

Another option will be that Token will have their own type Wing

Consider the above code:

bring cloud;
bring "cdktf" as cdktf;

let api = new cloud.Api();

let apiURL: TokenedStr = api.url;
let apiDomain = api.url.replace("http://", "");

log("apiURL = ${apiURL.token}"); // ${root/Default/cloud.Api#attrs.url}
log("apiDomain = ${apiDomain.token}"); // ${root/Default/cloud.Api#attrs.url}.replace("http://", "")
new cloud.Service(inflight () => {
    log("apiURL = ${apiURL}"); // http://127.0.0.1:49401
    log("apiDomain = ${apiDomain}"); // 127.0.0.1:49401
});

This means that TokenStr is a preflight class that is lifted into a str

it contains matching method to str

class TokenStr {
  pub replace(a: str, b: str): TokenStr; // once token is resolved, replace a with b
  pub length(): TokenNum;  
  pub token(): str // show the token representation a the token 
  // ...
}

[ekeren]

It might make more sense to have a inflight asStr():str method on the Token preflight class

[ekeren]

my solution will not work, we can't differentiate the type str and the type Token.

String and Token need to be the same type.

Calling url.replace("http", "https"); should:

• Work in inflight
• Fail in preflight during compilation if url is a Token and not a plain string, with some error: url is a Token and can't be called withreplaceduring preflight

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!

[yoav-steinberg]

Here: https://winglang.slack.com/archives/C048QCN2XLJ/p1709224395387679 we discussed the idea of a token type that can only be writable and appended to in preflight and is lifted into a str inflight. This is @eladb's final comment on the issue:

I propose a rename and then I support this proposal: Let’s call the tokenized string str and it will be write-only (and concatable) in preflight (basically the same as the token > type) and if you want to be able to read it/split it/etc you’d have to explicitly use something like readable_str (name TBD). It’s basically the same thing but the “default” is token. The fact that the default is more restrictive is great because it will encourage most APIs to be able to accept tokens for strings and only if they really need to manipulate it, they will use the subtype. I kind of like this because it will result in a more abstract API (readable_str is a subclass or str and not vice versa). Yes! I really like this direction. :heart:

This will avoid that case where preflight code manipulates a string that's actually a token resulting in a corrupted token or when we try reading the token string in preflight and getting a bad value. Once we have this change adding @ekeren's idea will enable some ability to manipulate the string in preflight.