4 ms·

Yet another example of the horrible mess unprincipled automatic type conversion causes. What prevents language designers from avoiding all these lurking bugs w

• anonymoushn 12y ago
  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 >_>
  • Pitarou 12y ago
    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?
    • mateuszf 12y ago
      Python example with str and int are IMHO much better. They require only little more typing, but are very readable and explicit.
    • danbruc 12y ago
      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.
• SixSigma 12y ago
  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
• VMG 12y ago
  > 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.
  • CmonDev 12y ago
    In some dynamic weakly-typed languages you don't even need to try that hard to achieve the abuse.
• deleted 12y ago
  [deleted]
• reycharles 12y ago
  Idris has a type class that is pretty much this: https://github.com/idris-lang/Idris-dev/blob/master/libs/prelude/Prelude/Cast.idr 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 https://gist.github.com/reynir/b3d32f07d69366dd2bc3
• anon4 12y ago
  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
  • Pitarou 12y ago
    That's awesome. Have a unicode trophy () as a prize: 🏆