You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The interaction between implicit conversions and constructor overloading can lead to unintuitive constructor selection, particularly when multiple constructors are viable through different sets of implicit conversions.
For instance, in the provided example there exists an overloaded __init__, one accepting three SIMD[DType.uint8, 1] and one accepting a SIMD[DType.uint8, 4], Bool and Int. If we consider the calls to initialise the struct, despite all these implicit casts useful independently, this appears to lead in a preference of the second __init__ function, which was unintended in my case.
Perhaps there is an underlying feature-request for warnings on unused default arguments as well?
On the contrary, changing the second constructor to
prompts the mojo-lsp-server to return the following Error:
ambiguous call to `__init__`, each candidate requires 3 implicit conversions, disambiguate with and explicit cast
However, the compiler still executes the script.
The LSP appears to have an existing check for ambiguous calls, which is not mirrored in the compiler's behavior. This seems to be a bug. Additionally, the discreprency between handling Bool, Bool and Bool, Int arguments does not seem consistent in defining an ambiguous call.
Bug description
The interaction between implicit conversions and constructor overloading can lead to unintuitive constructor selection, particularly when multiple constructors are viable through different sets of implicit conversions.
For instance, in the provided example there exists an overloaded
__init__
, one accepting threeSIMD[DType.uint8, 1]
and one accepting aSIMD[DType.uint8, 4]
,Bool
andInt
. If we consider the calls to initialise the struct, despite all these implicit casts useful independently, this appears to lead in a preference of the second__init__
function, which was unintended in my case.On the contrary, changing the second constructor to
prompts the
mojo-lsp-server
to return the following Error:However, the compiler still executes the script.
The LSP appears to have an existing check for ambiguous calls, which is not mirrored in the compiler's behavior. This seems to be a bug. Additionally, the discreprency between handling
Bool
,Bool
andBool
,Int
arguments does not seem consistent in defining an ambiguous call.Steps to reproduce
unused2
commentedunused2
uncommentedSystem information
The text was updated successfully, but these errors were encountered: