<p>Many languages that has static typing or type hinting, support user-defined casting functions that are called automatically when a function expects another type that the parameter could be cast into.</p>
<p>But I think most of them don't support this kind of implicit casting across multiple levels. That is, if the user has only defined the casting from A to B, and from B to C, but called a function that expects a parameter in type C with a parameter of type A, without writing the type conversions explicitly, it usually wouldn't compile.</p>
<p>Supporting this by default indeed sounds like a horrible idea. But with some obvious patches such as precedence and directives to block indirect casting, it's not like it is inherently evil.</p>
<p>If it actually works, it would allow using types much more freely.</p>
<p>What are the pitfalls? Do they make indirect implicit casting really infeasible?</p>
<p>This question is about user-defined casting. Casting to base classes across multiple levels is usually not a problem, but it is more like a special case.</p>

<type-conversion><type-coercion>
What are the pitfalls of indirect implicit casting?
CC BY-SA 4.0
2023-07-24T19:32:07.703Z
My use case is [the unsafe string thing in another question](https://langdev.stackexchange.com/a/2534/1149). A bit confusingly, sometimes it might be helpful to cast from strings to unsafe strings by escaping, but functions expecting unsafe strings would be more difficult to use without indirect implicit casting, if there were many other types that could be cast into strings.
user23013
CC BY-SA 4.0
2023-07-25T17:39:44.547Z
I have a mental model with sort of two types of implicit casts: you could perhaps call them "true" casts and "convenience" casts. If the two sides of the cast are truly interchangeable, chain all you like. For example, automatic dereferencing in Rust will (I think) do an arbitrary number of conversions. This is fine, since the conversion is sort of a formality; it does not change meaning. But you wouldn't want to do this with "convenience" casts, like turning integers into strings.
Glenn Willen
CC BY-SA 4.0
2023-07-26T00:13:04.333Z
FYI in C# we considered this question and decided that when evaluating a *user defined conversion*, the compiler will automatically insert *built-in conversions* on "either side" of the user-defined conversion, but will never "chain" user-defined conversions.
Eric Lippert
CC BY-SA 4.0
2023-07-26T00:16:42.583Z
For example, if you have a user-defined explicit conversion from non-nullable struct `S` to `decimal?`, say, then you can cast `S?` to `int` and the compiler will do `S? -> S -> decimal? -> decimal -> int`, all of which are explicit conversions but only one of which is user-defined.  That led to some complexity (that is, weird bugs!) in the compiler but it avoided some of the weird cases described in answers.
Eric Lippert
CC BY-SA 4.0
2023-07-26T06:21:20.283Z
For frame challenge answers: [Pros and cons of user-defined implicit casting](https://langdev.stackexchange.com/q/2565/1149).
user23013
CC BY-SA 4.0
2023-07-26T09:06:49.120Z
Is this asking about _casting_, or _converting_? (Some of the comments and answers mention converting between different numeric types, which is usually about storage and interpretation of bit patterns and not just about types — even though some languages confuse the two.)
gidds
CC BY-SA 4.0
2023-07-26T09:22:19.410Z
@gidds Either, as long as it is user-defined and implicit. This is only about the syntax and not how the work is really done. I don't think it makes a difference.
user23013
<p>TL;DR: Don't offer implicit casts at all (besides trivial, reliable ones that you define in your language specification, e.g. casts from <code>int8</code> to <code>int32</code>).</p>
<p>(Disclaimer: I am an old-school Java enthusiast, so my answer might be biased.)</p>
<h2>Language Clarity</h2>
<p>I prefer a language to be clear, meaning that everything that happens (1) is visible in the source code. And when knowing a language, I can always tell where to look for the &quot;contract&quot; of that element: either in the language specification, or in an easily-found place in user or library code.</p>
<p>E.g. if I see an assignment opererator, I like its semantics to be well-defined in the language specification, without the need to search (or navigate) through source code and libraries to grasp its meaning.</p>
<h2>IDE Friendliness</h2>
<p>If every non-trivial action is found explicitly in the source code, it not only makes the code clear, it also gives your IDE a logical place from where to navigate to the relevant definition.</p>
<p>If you have hidden, non-trivial casting (no matter whether single or multiple steps), you see a variable of type B being assigned an expression of type A, and nothing in the source code that represents the conversion. Only a sophisticated IDE can give you a hint that there is more than just an assignment going on.</p>
<p>Even for this IDE it's non-trivial to provide a navigation point where to offer the &quot;goto definition&quot; action. In an assignment statement, it might choose the <code>=</code> operator, which might already be overloaded depending on your language features, so it needs a submenu, offering the overloaded assignment operator and the various cast implementations involved here.</p>
<p>Probably, you'll also allow implicit casting not only for assignments, but also within expressions, e.g. in method call arguments. Where do you expect the IDE to offer the navigation point then?</p>
<h2>Ambiguity and Complexity</h2>
<p>Others have already discussed that in-depth, so there's no need to repeat those aspects here.</p>
<p>But I'd like to mention one additional pitfall. If you write</p>
<pre><code>A a;
B b = a;
</code></pre>
<p>This calls the A-to-B cast. If now, a developer introduces a superclass (or interface, supertype or whatever you might call it in your language) of <code>B</code>, named <code>SB</code>, and follows the good practice to declare a variable with the most generic type that still matches the requirements:</p>
<pre><code>A a;
SB b = a;
</code></pre>
<p>Then another cast, being A-to-SB, appears as candidate, and probably a few others if <code>SB</code> has more than one subclass. Now you need a disambiguation rule which one to choose, and it's very likely that it will no longer result in the A-to-B cast. So, by just following a good practice, this developer broke the program.</p>
<h2>Questionable Benefit</h2>
<p>Evrything you can do with implicit casts, you can as well do with explicit ones. It only saves you a few characters. IMHO these few characters aren't worth the pain.</p>
<hr />
<p>(1) What counts as &quot;happens&quot; is subject to interpretation.</p>
<p>Is treating an <code>int8</code> as <code>int32</code> something that matters enough to become a visible action? You can argue that it's now a longer bit string, containing 32 instead of 8 bits, but you can also argue that a number like e.g. <code>96</code> stays the same, no matter whether you store it as an 8-bit or a 32-bit pattern. Many existing languages do implicit casts with this type of conversion, and force you to write explicit casts only if there is a risk of losing some information.</p>
<p>If the conversion involves user code, then probably everybody will agree that there is something &quot;happening&quot;, and then I like that to be explicitly visible.</p>

CC BY-SA 4.0
2023-07-25T12:07:23.317Z
2023-07-26T08:17:08.090Z
2023-07-26T08:17:08.090Z
Ralf Kleberhoff
CC BY-SA 4.0
2023-07-25T13:56:12.577Z
"follows the good practice to declare a variable with the most generic type that still matches the requirements" - one of the requirements of `b`'s type is "can be constructed from an A with the correct semantics".
Yakk - Adam Nevraumont
CC BY-SA 4.0
2023-07-25T17:45:30.353Z
If 1+2 has a type, say int8, then "int64 x = 1 + 2;" is illegal without an implicit conversion. (If it's boosted to int64, then "int8 x = 1 + 2;" is illegal; and int8 -> int64 is a safe conversion, while int64 -> int8 is definitely not.) Unless you have but one integer type, presumably either the largest hardware supported type or an unbounded integer (i.e. the most expensive choice), implicit casts are going to be widespread and noisy.
prosfilaes
CC BY-SA 4.0
2023-07-25T18:25:08.657Z
I've written a program for a fairy chess game with 8x12 boards in Ada, which lets you define distinct types, row = 1..8 and column = 1..12. That prevented some bugs, but required bunches of noisy casts; arguably, the loss in readability cost more in bug prevention than the strong typing gave. Even in Ada, which is pretty strict typing, that was optional, and that seems pretty clearly the right choice.
prosfilaes
CC BY-SA 4.0
2023-07-26T07:59:06.327Z
I see, I should have been clearer in the wording of my answer, as I do support implicit conversions of e.g. different-sized integers - casts that are defined in the language specification, not by some user code. I'll edit my answer.
Ralf Kleberhoff
<p>Frame challenge: The question assumes that implicit casting is okay.</p>
<p>The biggest problem I see with supporting indirect implicit casting is that you are supporting implicit casting. Don't do it, every typed language that supports implicit casting has come to regret it.</p>
<p>Implicit casts create difficult to track down bugs. Which is why lint has a setting to treat implicit casts as errors. And why coding standards usually have a &quot;all casts must be explicit&quot; line somewhere in them.</p>
<p><a href="https://doc.rust-lang.org/rust-by-example/index.html" rel="nofollow noreferrer">Rust</a> which was designed to fix many of the security flaws/foot self-perforation of C/C++ while allowing for the same performance/low level control, does not allow implicit casting.</p>
<p>TLDR: Don't support implicit casts, meaningful verbosity makes code clearer.</p>

CC BY-SA 4.0
2023-07-25T17:34:15.267Z
2023-07-25T17:34:15.267Z
Questor
CC BY-SA 4.0
2023-07-25T17:40:58.620Z
Rust does allow chained automatic dereferences, though, which I claim are a type of implicit cast. So it's not as simple as that. It's about which casts make sense to give this treatment.
Glenn Willen
CC BY-SA 4.0
2023-07-25T18:41:31.017Z
Rust *does* allow implicit type conversions in some contexts. Notably, the `?` operator (which either unwraps an `Ok` result or otherwise returns early from the containing function with an `Err` result) implicitly converts the error value to the expected type, if an implementation of the `Into` trait is available. There are also implicit conversions between between types like `&&T` and `&T`, and from arrays to slices. See [here](https://doc.rust-lang.org/reference/type-coercions.html) and [here](https://www.lurklurk.org/effective-rust/casts.html#coercion) for more information.
kaya3
<h1>Ambiguity and its Consequences</h1>
<p>One immediate downside is that the chain of casts may be ambiguous.  For example, suppose that we have types <code>A</code>–<code>F</code> and the following implicit conversions available:</p>
<ul>
<li><code>A</code> can implicitly become <code>B</code> or <code>C</code>.</li>
<li>Both <code>B</code> and <code>C</code> can implicitly become <code>D</code> or <code>E</code>.</li>
<li>Both <code>D</code> and <code>E</code> can implicitly become <code>F</code>.</li>
</ul>
<p>Then there are four chains of conversion that the compiler/interpreter needs to decide among:</p>
<ul>
<li><code>A</code> → <code>B</code> → <code>D</code> → <code>F</code></li>
<li><code>A</code> → <code>B</code> → <code>E</code> → <code>F</code></li>
<li><code>A</code> → <code>C</code> → <code>D</code> → <code>F</code></li>
<li><code>A</code> → <code>C</code> → <code>E</code> → <code>F</code></li>
</ul>
<p>Ways to resolve such ambiguities fall on a spectrum from fixed policy to wholly programmer-disambiguated, but no point on the spectrum is very satisfactory.</p>
<h2>Fixed Policy</h2>
<p>Suppose that we use a fixed policy to resolve the conversion path.  Now we have at least four problems:</p>
<ul>
<li>Like with any overzealous DWIM feature, the first problem is that the policy could choose a path other than the one the programmer intended, and it's hard to see how the programmer could be warned about that until the bug causes problems at runtime.</li>
<li>Another huge downside is the fact that introducing a new implicit cast can have side effects in code unrelated to either the source or destination type.  Take the example above, suppose that an <code>A</code> → <code>G</code> implicit cast is already possible, and consider what happens when we introduce a <code>G</code> → <code>E</code> implicit cast: we create the path <code>A</code> → <code>G</code> → <code>E</code> → <code>F</code>, which the policy may select as the new way to convert from <code>A</code> to <code>F</code> even though neither of those types were mentioned in the code we added.  That makes it difficult for programmers to predict what their code changes will do.</li>
<li>Related to the prior problem, unless we have a really good way to limit which implicit casts are in scope, the compiler/interpreter might have to search a lot of code (the whole program if we place no restrictions) just to enumerate the potential paths.  That raises a lot of issues for separate compilation, dynamic loading, etc.</li>
<li>If we keep adding intermediate steps with multiple options like in the example above, the number of candidate paths can be exponential in the program size.  That severely limits our choices for efficiently implementable disambiguation policies, mostly to greedy or bounded-lookahead strategies.</li>
</ul>
<h2>Programmer-Defined Policy</h2>
<p>Now consider the other extreme, where we allow the programmer to disambiguate.  At first glance, this seems like a win, since, e.g., they could specify the conversion path from <code>A</code> to <code>F</code> once instead of having to write a cast everywhere they need the conversion.  But, of course, they can already do that without indirect implicit casting: they would just write a new implicit cast from <code>A</code> to <code>F</code> defined as calling one intermediate cast on the result of another.  So at this end of a spectrum we've added a new language feature only to replicate what was probably already possible with direct implicit casts.  (One exception might be languages where it is difficult to add new implicit casts between externally defined types, but then it's better to address that shortcoming directly.)</p>
<p>In languages that have suitably powerful templates or generics or similar features, it's even possible to write rules that apply to many types in this way.  For instance, with your example about passing a non-string value to a function that uses the type system to require a properly escaped string, in a suitable language we could define a templated implicit cast from any stringifiable type T to escaped strings where the body just escapes whatever implicit stringification returns.</p>
<h2>Mixed Policy</h2>
<p>In the middle, we could have a default policy and allow the user to make tweaks, but then we just combine downsides: it remains easy to write bugs silently, we couple implicit casts with all kinds of unrelated code, we're limited in the quality of the defaults we can compute efficiently, and in the end we might not save the programmer any effort.</p>

CC BY-SA 4.0
2023-07-24T19:53:07.240Z
2023-07-25T00:16:48.700Z
2023-07-25T00:16:48.700Z
Wheelwright
CC BY-SA 4.0
2023-07-25T13:30:42.320Z
Ambiguities will also show up in Type Inference. In Java there's not much of it -- just `var` -- but in some languages most local types are fully inferred -- saving quite a bit of typing -- which... would probably not work well with any ambiguity. Languages where everything is an `Object` already suffer from this, as suddenly a list where you insert a string and an integer can be inferred to be a list of Objects... and the developer is left wondering _why oh why_.
Matthieu M.
CC BY-SA 4.0
2023-07-25T17:38:59.830Z
@MatthieuM. I don't understand why the developer would be left wondering; if you have a list with a string and an integer, you have a List[Union(String, Integer)]; since Java doesn't have union types (generally only functional languages do), it's a List[Object], like any Lisp or Python programmer would expect.
prosfilaes
CC BY-SA 4.0
2023-07-26T09:55:43.493Z
@prosfilaes: If it's intentional, there's no issue. If it's not... and the compiler complains that the user is attempting to pass/return a List[Object] where a List[String] is expected, then the user is left wondering why the hell the compiler is so stupid, since it's obviously a List[String], and they will have to scrutinize all uses of the List to spot the one place in their code where actually they inserted an Integer by mistake.
Matthieu M.
<h1>Type checking is dramatically less effective</h1>
<p>The main goal of type checking is to notice bugs before they happen, and to present them explicitly as bugs instead of causing the program to continue running, but with very weird and unexpected behavior.</p>
<p>The problem with long chains of indirect casts is that they mean the compiler is very often unable to detect bugs, since passing even a completely unrelated type in place of another could be valid through some long chain of (individually reasonable) implicit casts.</p>
<p>Take, for example, the following rules:</p>
<ul>
<li>A number can be cast to a string</li>
<li>A string can be cast to a char array</li>
<li>An array can be cast to a set</li>
</ul>
<p>These chain together to mean that a number and a set are interchangeable. For example, if you were to pass the number <code>2181012</code> to a function expecting a set, you could end up with <code>{0, 1, 2, 8}</code>, and no warnings or errors.</p>
<p>Most chains of 2+ casts, with a few exceptions like autoboxing pointers, are semantically meaningless (e.g., think about a <code>Date</code> struct being implicitly cast to a UNIX timestamp, which is implicitly cast to a <code>Price</code> struct containing dollars and cents), and are quite likely to be bugs.</p>

CC BY-SA 4.0
2023-07-24T19:09:56.710Z
2023-07-24T19:09:56.710Z
rydwolf
CC BY-SA 4.0
2023-07-24T19:12:48.197Z
Languages like C# mitigate this by allowing you to have `implicit` and `explicit` casts, so a number could have `explicit operator string()` and break this implicit triple-cast. Of course, I don't think C# has implicit triple-casts in the first place.
Bbrk24
CC BY-SA 4.0
2023-07-24T19:33:55.000Z
There are languages like C++ that supports none of the 3 conversions. So I think it might be still manageable to just mark them as the worse type of conversions and disallow only them for indirect casting.
user23013
CC BY-SA 4.0
2023-07-24T20:01:58.487Z
@user23013 That's true I guess; if the implicit casts are more conservative and sensible, this wouldn't be as big of a factor.
rydwolf
CC BY-SA 4.0
2023-07-24T23:13:31.607Z
Another type-checking related problem is that method overloading would become a lot more complicated. Even if there's no ambiguity to the compiler, there would probably be cases that catch the programmer unawares.
user
CC BY-SA 4.0
2023-07-27T18:15:40.750Z
I found number to string to be dodgy automatic cast in the first place. Casting a string to a set is something I actually want to do occasionally.
Joshua
# What are the pitfalls of indirect implicit casting?
Posted by: username_0 on 2023-07-24
Many languages that has static typing or type hinting, support user-defined casting functions that are called automatically when a function expects another type that the parameter could be cast into.

But I think most of them don't support this kind of implicit casting across multiple levels. That is, if the user has only defined the casting from A to B, and from B to C, but called a function that expects a parameter in type C with a parameter of type A, without writing the type conversions explicitly, it usually wouldn't compile.

Supporting this by default indeed sounds like a horrible idea. But with some obvious patches such as precedence and directives to block indirect casting, it's not like it is inherently evil.

If it actually works, it would allow using types much more freely.

What are the pitfalls? Do they make indirect implicit casting really infeasible?

This question is about user-defined casting. Casting to base classes across multiple levels is usually not a problem, but it is more like a special case.
**Tags:** type-conversion type-coercion
> **Comments:**
> **username_0**: My use case is [the unsafe string thing in another question](https://langdev.stackexchange.com/a/2534/1149). A bit confusingly, sometimes it might be helpful to cast from strings to unsafe strings by escaping, but functions expecting unsafe strings would be more difficult to use without indirect implicit casting, if there were many other types that could be cast into strings.  
> **username_1**: I have a mental model with sort of two types of implicit casts: you could perhaps call them "true" casts and "convenience" casts. If the two sides of the cast are truly interchangeable, chain all you like. For example, automatic dereferencing in Rust will (I think) do an arbitrary number of conversions. This is fine, since the conversion is sort of a formality; it does not change meaning. But you wouldn't want to do this with "convenience" casts, like turning integers into strings.  
> **username_2**: FYI in C# we considered this question and decided that when evaluating a *user defined conversion*, the compiler will automatically insert *built-in conversions* on "either side" of the user-defined conversion, but will never "chain" user-defined conversions.  
> **username_2**: For example, if you have a user-defined explicit conversion from non-nullable struct `S` to `decimal?`, say, then you can cast `S?` to `int` and the compiler will do `S? -> S -> decimal? -> decimal -> int`, all of which are explicit conversions but only one of which is user-defined.  That led to some complexity (that is, weird bugs!) in the compiler but it avoided some of the weird cases described in answers.  
> **username_0**: For frame challenge answers: [Pros and cons of user-defined implicit casting](https://langdev.stackexchange.com/q/2565/1149).  
> **username_3**: Is this asking about _casting_, or _converting_? (Some of the comments and answers mention converting between different numeric types, which is usually about storage and interpretation of bit patterns and not just about types — even though some languages confuse the two.)  
> **username_0**: @gidds Either, as long as it is user-defined and implicit. This is only about the syntax and not how the work is really done. I don't think it makes a difference.  
---
## 4 answers
### Answer by username_9 on 2023-07-24. Score: 19 | Accepted answer
# Ambiguity and its Consequences

One immediate downside is that the chain of casts may be ambiguous. For example, suppose that we have types `A`–`F` and the following implicit conversions available:

* `A` can implicitly become `B` or `C`.
* Both `B` and `C` can implicitly become `D` or `E`.
* Both `D` and `E` can implicitly become `F`.

Then there are four chains of conversion that the compiler/interpreter needs to decide among:

* `A` → `B` → `D` → `F`
* `A` → `B` → `E` → `F`
* `A` → `C` → `D` → `F`
* `A` → `C` → `E` → `F`

Ways to resolve such ambiguities fall on a spectrum from fixed policy to wholly programmer-disambiguated, but no point on the spectrum is very satisfactory.

## Fixed Policy

Suppose that we use a fixed policy to resolve the conversion path. Now we have at least four problems:

* Like with any overzealous DWIM feature, the first problem is that the policy could choose a path other than the one the programmer intended, and it's hard to see how the programmer could be warned about that until the bug causes problems at runtime.
* Another huge downside is the fact that introducing a new implicit cast can have side effects in code unrelated to either the source or destination type. Take the example above, suppose that an `A` → `G` implicit cast is already possible, and consider what happens when we introduce a `G` → `E` implicit cast: we create the path `A` → `G` → `E` → `F`, which the policy may select as the new way to convert from `A` to `F` even though neither of those types were mentioned in the code we added. That makes it difficult for programmers to predict what their code changes will do.
* Related to the prior problem, unless we have a really good way to limit which implicit casts are in scope, the compiler/interpreter might have to search a lot of code (the whole program if we place no restrictions) just to enumerate the potential paths. That raises a lot of issues for separate compilation, dynamic loading, etc.
* If we keep adding intermediate steps with multiple options like in the example above, the number of candidate paths can be exponential in the program size. That severely limits our choices for efficiently implementable disambiguation policies, mostly to greedy or bounded-lookahead strategies.

## Programmer-Defined Policy

Now consider the other extreme, where we allow the programmer to disambiguate. At first glance, this seems like a win, since, e.g., they could specify the conversion path from `A` to `F` once instead of having to write a cast everywhere they need the conversion. But, of course, they can already do that without indirect implicit casting: they would just write a new implicit cast from `A` to `F` defined as calling one intermediate cast on the result of another. So at this end of a spectrum we've added a new language feature only to replicate what was probably already possible with direct implicit casts. (One exception might be languages where it is difficult to add new implicit casts between externally defined types, but then it's better to address that shortcoming directly.)

In languages that have suitably powerful templates or generics or similar features, it's even possible to write rules that apply to many types in this way. For instance, with your example about passing a non-string value to a function that uses the type system to require a properly escaped string, in a suitable language we could define a templated implicit cast from any stringifiable type T to escaped strings where the body just escapes whatever implicit stringification returns.

## Mixed Policy

In the middle, we could have a default policy and allow the user to make tweaks, but then we just combine downsides: it remains easy to write bugs silently, we couple implicit casts with all kinds of unrelated code, we're limited in the quality of the defaults we can compute efficiently, and in the end we might not save the programmer any effort.
> **Comments:**
> **username_10** (2023-07-25): Ambiguities will also show up in Type Inference. In Java there's not much of it -- just `var` -- but in some languages most local types are fully inferred -- saving quite a bit of typing -- which... would probably not work well with any ambiguity. Languages where everything is an `Object` already suffer from this, as suddenly a list where you insert a string and an integer can be inferred to be a list of Objects... and the developer is left wondering _why oh why_.  
> **username_6** (2023-07-25): @MatthieuM. I don't understand why the developer would be left wondering; if you have a list with a string and an integer, you have a List[Union(String, Integer)]; since Java doesn't have union types (generally only functional languages do), it's a List[Object], like any Lisp or Python programmer would expect.  
> **username_10** (2023-07-26): @prosfilaes: If it's intentional, there's no issue. If it's not... and the compiler complains that the user is attempting to pass/return a List[Object] where a List[String] is expected, then the user is left wondering why the hell the compiler is so stupid, since it's obviously a List[String], and they will have to scrutinize all uses of the List to spot the one place in their code where actually they inserted an Integer by mistake.  
---
### Answer by username_11 on 2023-07-24. Score: 25
# Type checking is dramatically less effective

The main goal of type checking is to notice bugs before they happen, and to present them explicitly as bugs instead of causing the program to continue running, but with very weird and unexpected behavior.

The problem with long chains of indirect casts is that they mean the compiler is very often unable to detect bugs, since passing even a completely unrelated type in place of another could be valid through some long chain of (individually reasonable) implicit casts.

Take, for example, the following rules:

* A number can be cast to a string
* A string can be cast to a char array
* An array can be cast to a set

These chain together to mean that a number and a set are interchangeable. For example, if you were to pass the number `2181012` to a function expecting a set, you could end up with `{0, 1, 2, 8}`, and no warnings or errors.

Most chains of 2+ casts, with a few exceptions like autoboxing pointers, are semantically meaningless (e.g., think about a `Date` struct being implicitly cast to a UNIX timestamp, which is implicitly cast to a `Price` struct containing dollars and cents), and are quite likely to be bugs.
> **Comments:**
> **username_12** (2023-07-24): Languages like C# mitigate this by allowing you to have `implicit` and `explicit` casts, so a number could have `explicit operator string()` and break this implicit triple-cast. Of course, I don't think C# has implicit triple-casts in the first place.  
> **username_0** (2023-07-24): There are languages like C++ that supports none of the 3 conversions. So I think it might be still manageable to just mark them as the worse type of conversions and disallow only them for indirect casting.  
> **username_11** (2023-07-24): @user23013 That's true I guess; if the implicit casts are more conservative and sensible, this wouldn't be as big of a factor.  
> **username_13** (2023-07-24): Another type-checking related problem is that method overloading would become a lot more complicated. Even if there's no ambiguity to the compiler, there would probably be cases that catch the programmer unawares.  
> **username_14** (2023-07-27): I found number to string to be dodgy automatic cast in the first place. Casting a string to a set is something I actually want to do occasionally.  
---
### Answer by username_4 on 2023-07-25. Score: 3
TL;DR: Don't offer implicit casts at all (besides trivial, reliable ones that you define in your language specification, e.g. casts from int8 to int32).
(Disclaimer: I am an old-school Java enthusiast, so my answer might be biased.)
Language Clarity
I prefer a language to be clear, meaning that everything that happens (1) is visible in the source code. And when knowing a language, I can always tell where to look for the "contract" of that element: either in the language specification, or in an easily-found place in user or library code.
E.g. if I see an assignment opererator, I like its semantics to be well-defined in the language specification, without the need to search (or navigate) through source code and libraries to grasp its meaning.
IDE Friendliness
If every non-trivial action is found explicitly in the source code, it not only makes the code clear, it also gives your IDE a logical place from where to navigate to the relevant definition.
If you have hidden, non-trivial casting (no matter whether single or multiple steps), you see a variable of type B being assigned an expression of type A, and nothing in the source code that represents the conversion. Only a sophisticated IDE can give you a hint that there is more than just an assignment going on.
Even for this IDE it's non-trivial to provide a navigation point where to offer the "goto definition" action. In an assignment statement, it might choose the = operator, which might already be overloaded depending on your language features, so it needs a submenu, offering the overloaded assignment operator and the various cast implementations involved here.
Probably, you'll also allow implicit casting not only for assignments, but also within expressions, e.g. in method call arguments. Where do you expect the IDE to offer the navigation point then?
Ambiguity and Complexity
Others have already discussed that in-depth, so there's no need to repeat those aspects here.
But I'd like to mention one additional pitfall. If you write
A a;
B b = a;

This calls the A-to-B cast. If now, a developer introduces a superclass (or interface, supertype or whatever you might call it in your language) of B, named SB, and follows the good practice to declare a variable with the most generic type that still matches the requirements:
A a;
SB b = a;

Then another cast, being A-to-SB, appears as candidate, and probably a few others if SB has more than one subclass. Now you need a disambiguation rule which one to choose, and it's very likely that it will no longer result in the A-to-B cast. So, by just following a good practice, this developer broke the program.
Questionable Benefit
Evrything you can do with implicit casts, you can as well do with explicit ones. It only saves you a few characters. IMHO these few characters aren't worth the pain.

(1) What counts as "happens" is subject to interpretation.
Is treating an int8 as int32 something that matters enough to become a visible action? You can argue that it's now a longer bit string, containing 32 instead of 8 bits, but you can also argue that a number like e.g. 96 stays the same, no matter whether you store it as an 8-bit or a 32-bit pattern. Many existing languages do implicit casts with this type of conversion, and force you to write explicit casts only if there is a risk of losing some information.
If the conversion involves user code, then probably everybody will agree that there is something "happening", and then I like that to be explicitly visible.
> **Comments:**
> **username_5** (2023-07-25): "follows the good practice to declare a variable with the most generic type that still matches the requirements" - one of the requirements of `b`'s type is "can be constructed from an A with the correct semantics".  
> **username_6** (2023-07-25): If 1+2 has a type, say int8, then "int64 x = 1 + 2;" is illegal without an implicit conversion. (If it's boosted to int64, then "int8 x = 1 + 2;" is illegal; and int8 -> int64 is a safe conversion, while int64 -> int8 is definitely not.) Unless you have but one integer type, presumably either the largest hardware supported type or an unbounded integer (i.e. the most expensive choice), implicit casts are going to be widespread and noisy.  
> **username_6** (2023-07-25): I've written a program for a fairy chess game with 8x12 boards in Ada, which lets you define distinct types, row = 1..8 and column = 1..12. That prevented some bugs, but required bunches of noisy casts; arguably, the loss in readability cost more in bug prevention than the strong typing gave. Even in Ada, which is pretty strict typing, that was optional, and that seems pretty clearly the right choice.  
> **username_4** (2023-07-26): I see, I should have been clearer in the wording of my answer, as I do support implicit conversions of e.g. different-sized integers - casts that are defined in the language specification, not by some user code. I'll edit my answer.  
---
### Answer by username_7 on 2023-07-25. Score: 2
Frame challenge: The question assumes that implicit casting is okay.

The biggest problem I see with supporting indirect implicit casting is that you are supporting implicit casting. Don't do it, every typed language that supports implicit casting has come to regret it.

Implicit casts create difficult to track down bugs. Which is why lint has a setting to treat implicit casts as errors. And why coding standards usually have a "all casts must be explicit" line somewhere in them.

[Rust](https://doc.rust-lang.org/rust-by-example/index.html) which was designed to fix many of the security flaws/foot self-perforation of C/C++ while allowing for the same performance/low level control, does not allow implicit casting.

TLDR: Don't support implicit casts, meaningful verbosity makes code clearer.
> **Comments:**
> **username_1** (2023-07-25): Rust does allow chained automatic dereferences, though, which I claim are a type of implicit cast. So it's not as simple as that. It's about which casts make sense to give this treatment.  
> **username_8** (2023-07-25): Rust *does* allow implicit type conversions in some contexts. Notably, the `?` operator (which either unwraps an `Ok` result or otherwise returns early from the containing function with an `Err` result) implicitly converts the error value to the expected type, if an implementation of the `Into` trait is available. There are also implicit conversions between between types like `&&T` and `&T`, and from arrays to slices. See [here](https://doc.rust-lang.org/reference/type-coercions.html) and [here](https://www.lurklurk.org/effective-rust/casts.html#coercion) for more information.  
---
