From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp55.i.mail.ru (smtp55.i.mail.ru [217.69.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id E842A42F4AD for ; Mon, 22 Jun 2020 14:52:30 +0300 (MSK) From: Mergen Imeev Message-ID: <94708d29-e20d-2d2c-9c8f-67471d972661@tarantool.org> Date: Mon, 22 Jun 2020 14:52:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: [Tarantool-discussions] Implicit cast for assignment between numeric types and type mismatch error description. List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: pgulutzan@ocelot.ca, tarantool-discussions@dev.tarantool.org, korablev@tarantool.org, Vladislav Shpilevoy , tsafin@tarantool.org 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'