From: Mergen Imeev <imeevma@tarantool.org> To: pgulutzan@ocelot.ca, tarantool-discussions@dev.tarantool.org, korablev@tarantool.org, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tsafin@tarantool.org Subject: [Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description. Date: Mon, 22 Jun 2020 14:52:28 +0300 [thread overview] Message-ID: <94708d29-e20d-2d2c-9c8f-67471d972661@tarantool.org> (raw) Hello Peter! I have two questions. The first. I am sorry to ask about this again, but I want to discuss once again the implicit cast for assignment between numeric types. I wrote earlier that I plan to use C rules for implicit casting. However, after implementation, this looks terribly wrong for me. Temporarily, I decided to allow implicit casting only if the number after conversion from one type to another using C rules and back remains unchanged. For example, a double 50.0 can be implicitly cast to an integer 50, but a double 50.5 cannot be cast to an integer, and an integer 2^60-1 cannot be cast to a double. However, I am not sure if this is correct. Could you suggest rules for implicit casting to assign numeric types? The second question is about type mismatch error text. We currently have two types of type mismatch errors. The first: - 'Type mismatch: can not convert some_text to integer' The second: - 'Type mismatch: can not convert text to integer' In the first case, we use the value in the error description, in the second we use the type. Now we have decided on the same opinion. We have 3 options: 1) use value in error description: Type mismatch: can not convert 'some_text' to integer 2) use type in error description: Type mismatch: can not convert text to integer 3) use both in error description: Type mismatch: can not convert 'some_text'(text) to integer The first and third options look a little unsafe, since the values will be shown in the logs. However, they provide more information than the second option. Which one do you think is the best? Or maybe you can offer another option? In addition, we must remember that at some point the description becomes the same as in Lua (issue #5074): 'Tuple field 1 type does not match one required by operation: expected integer'
next reply other threads:[~2020-06-22 11:52 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-22 11:52 Mergen Imeev [this message] 2020-06-22 18:43 ` Peter Gulutzan 2020-06-23 16:15 ` Mergen Imeev 2020-06-23 19:42 ` Peter Gulutzan 2020-06-25 8:02 ` Mergen Imeev 2020-06-25 19:39 ` Peter Gulutzan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=94708d29-e20d-2d2c-9c8f-67471d972661@tarantool.org \ --to=imeevma@tarantool.org \ --cc=korablev@tarantool.org \ --cc=pgulutzan@ocelot.ca \ --cc=tarantool-discussions@dev.tarantool.org \ --cc=tsafin@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox