How about something like this

    >>> print(str(x) + y)
    "12"
    >>> print(x + int(y))
    3
    >>> print (x+y)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: unsupported operand type(s) for +: 'int' and 'str'

That's already Python

you can already do exactly that in Python with a bit of evil magic:

  $ cat evil.py
  class cast(object):
      def __init__(self, x):
          if isinstance(x, cast):
              self.x = x.x
          else:
              self.x = x

      def __add__(self, other):
          return other.__class__(self.x) + other

      def __radd__(self, other):
          return other + other.__class__(self.x)
  

  $ python3 -i evil.py 
  >>> a = 1
  >>> b = "2"
  >>> a + b
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'int' and 'str'
  >>> cast(a) + b
  '12'
  >>> a + cast(b)
  3
  >>> cast(a) + cast(b)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "evil.py", line 9, in __add__
      return other.__class__(self.x) + other
    File "evil.py", line 9, in __add__
    ... repeated many times ...
    File "evil.py", line 9, in __add__
      return other.__class__(self.x) + other
  RuntimeError: maximum recursion depth exceeded

That's awesome. Have a unicode trophy (🏆) as a prize:

🏆

Idris has a type class that is pretty much this: https://github.com/idris-lang/Idris-dev/blob/master/libs/pre...

Here's an example interaction. There's a difference, though, since + is only for {Num instance,Fin} addition while ++ is {String,List,Vect} concatenation.

https://gist.github.com/reynir/b3d32f07d69366dd2bc3

> Yet another example of the horrible mess unprincipled automatic type conversion causes.

I think you can abuse nearly every language to write crazy code in one way or other.

In some dynamic weakly-typed languages you don't even need to try that hard to achieve the abuse.

Why is this preferable to a set of functions that return a particular type? Most uses of such a cast function would be something like

  cast(unknown_type) <op> known_type

The programmer could just write tostring or tonumber instead of cast, if the type of the other operand is known >_>

Automatic type casting remains popular because it reduces the syntactic and cognitive overhead. I'm suggesting that a better solution would be to retain explicit casting, but minimise the overheads.

So, to take things a step further, lets use, say, the $ operator for casting. Then we have:

    >>> x = 1
    >>> y = "2"
    >>> print($x + y)
    3
    >>> print(x + $y)
    "12"
    >>> print($x + $y)
    CastError: ...

What do you think?

Python example with str and int are IMHO much better. They require only little more typing, but are very readable and explicit.

The proper way to do this is using something like TryParse() and ToString() and to handle the case of failing to parse the string as a number and maybe even specifying the locale for both operations. If you are absolutely sure that parsing can not fail you can use Parse() and omit the error handling.