Hackathon feedback - why can't receivers be simple functions?

[talkol]

Users found this code confusing:

message Add {
    amount: Int as uint32;
}

message Subtract {
    amount: Int as uint32;
}

contract Counter {

    receive(msg: Add) {
        // ...
    }

    receive(msg: Subtract) {
        // ...
    }
}

Questions:

• "why don't these functions have names?"
• "how can you know which function you're calling?"

They proposed a more familiar syntax that would not bring questions and will look more like other languages:

contract Counter {

    recv fun Add(amount: Int as uint32) {
        // ...
    }

    recv fun Subtract(amount: Int as uint32) {
        // ...
    }
}

[ex3ndr]

This is due the fact that calling this method more than once could lead to a huge number of possible bugs. This functions are not callable by anything except blockchain itself.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Tal Kol @.> Sent: Sunday, February 26, 2023 3:48:21 PM To: tact-lang/tact @.> Cc: Subscribed @.***> Subject: [tact-lang/tact] Hackathon feedback - why can't receivers be simple functions? (Issue #9)

Users found this code confusing:

message Add { amount: Int as uint32; }

message Subtract { amount: Int as uint32; }

contract Counter {

receive(msg: Add) {
    // ...
}

receive(msg: Subtract) {
    // ...
}

}

Questions:

• "why don't these functions have names?"
• "how can you know which function you're calling?"

They proposed a more familiar syntax that would not bring questions and will look more like other languages:

contract Counter {

recv fun Add(amount: Int as uint32) {
    // ...
}

recv fun Subtract(amount: Int as uint32) {
    // ...
}

}

— Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftact-lang%2Ftact%2Fissues%2F9&data=05%7C01%7C%7C0bf239cc6e3348ff432208db17ef5df0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638130089061119615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JMLC8Dsd2aIYs2Hiy1YeiGl0U%2FwZGfFV8prtsqhz6K0%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAADB2E5RKT6OSJJFTPGZEMLWZM7ILANCNFSM6AAAAAAVINMF7Y&data=05%7C01%7C%7C0bf239cc6e3348ff432208db17ef5df0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638130089061119615%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F5zQK3CqTm%2BKFov37D22zN%2FHF6JX4blMAAR%2FBygVIII%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[talkol]

This could still be the case.

Notice that the proposed syntax starts these function with recv fun Add() so they're easily identifiable - meaning the compiler will not allow you to call recv functions directly. The proposal is just syntactic sugar, they're not actually internal functions.

[Gusarich]

having message structs defined separately is better. for example, in jetton wallets you both send and receive InternalTransfer messages.

[novusnota]

If anything, I'd simply like a small alias internal, which would be the same as writing receive.

Rationale goes as follows — one can receive messages in Tact, which can be of 2 main types: internal and external, plus one sub-type for bounced messages. Therefore, we could have: internal (aka receive), bounced, external.

UPD: or recv_internal, recv_bounced and recv_external to be FunC-like :)

[anton-trunov]

I think keeping contract interfaces explicitly in messages is way better than recovering this information from function signatures.