MessageCommon::from should be inside Message

[tar-xzf]

A field from is missing from all MessageKind types except of MessageCommon. E.g. it is not possible to find out who created the topic since ForumTopicCreated lacks it.

An example could be found in the existing test types::message::tests::topic_created. The json value from the test is deserealized into the following value, note that the field from is absent:
Message { id: MessageId(4), thread_id: Some(ThreadId(MessageId(4))), date: 2023-02-01T05:25:39Z, chat: Chat { id: ChatId(-1001847508954), kind: Public(ChatPublic { title: Some("twest"), kind: Supergroup(PublicChatSupergroup { username: None, active_usernames: None, is_forum: true, sticker_set_name: None, can_set_sticker_set: None, permissions: None, slow_mode_delay: None, linked_chat_id: None, location: None, join_to_send_messages: None, join_by_request: None }), description: None, invite_link: None, has_protected_content: None }), photo: None, pinned_message: None, message_auto_delete_time: None, has_hidden_members: false, has_aggressive_anti_spam_enabled: false }, via_bot: None, kind: ForumTopicCreated(MessageForumTopicCreated { forum_topic_created: ForumTopicCreated { name: "???", icon_color: [142, 238, 152], icon_custom_emoji_id: Some("5312536423851630001") } }) }

Related: in the telegraf library, the base message type contains optional fields from, sender_chat, and is_topic_message. In teloxide, these are only present in MessageCommon.

[WaffleLapkin]

Life would be so much easier if telegram provided decent docs 😞

I agree, from, sender_chat, and is_topic_message should be moved to Message type. I think we may learn from how telegraf handles message type..

(if anyone wants to fix this issue, feel free to @teloxidebot claim it and work on a fix)

[tar-xzf]

I could fix it. Removing a public field breaks the API. Are you okay with it?

---

Life would be so much easier if telegram provided decent docs 😞

You probably already settled on a design and wouldn't like this, but anyway, just a thought.

It could be a single struct Message with a lot of optional fields and no kinds, just like how it is described in the Telegram Bot API docs. Semantically, it's a difference between two options (an example):

• This update contains information about a closed topic. IOW, it is about a closed topic.
• This update contains information about a closed topic and nothing else. IOW, it has info about a closed topic.

Separate message kinds provide crate users this "and nothing else" guarantee, but is there any use for it?
In a bot, you probably want to subscribe to specific events. The is/has dichotomy doesn't make a big difference here, but the former is harder to maintain for you.

[WaffleLapkin]

@tar-xzf how else do you fix this, without breaking changes?) besides, we already have a few breaking changes in the master branch. In other words yes, we are okay with this.