On Wednesday, 4 June 2014 at 21:02:21 UTC, Craig Dillabaugh wrote:
However, my primary point was that adding a string to a number
is really an 'undefined' operation. So I don't think such
automatic casting is (generally) helpful.
Yeah, I'm generally against it... but I have a weird view of
typing.
The way I see it, you should go either strong and static or
dynamic and weak - I hate the middle ground.
So, in my view:
Best (like D):
string a = "10"; int b = 20;
a + b; // compile time error: cannot do string + int
Sometimes ok (my jsvar/script language also PHP and some others):
var a = "10"; var b = 20;
a + b; // 30
Blargh (javascript):
var a = "10"; var b = 20;
a + b; // "1020"
Hatred:
var a = "10"; var b = 20;
a + b; // throws an exception at run time
The D one is best because it draws your attention to something
that is imperfect immediately and reliably via a compilation
error. Then you can solve it with to!int or
whatever easily.
The weak+dynamic is passable to me because it actually mostly
works. The operator you choose coerces the arguments and gives
something basically usable. I'd be ok if it
threw an exception in the case of a string that cannot be sanely
converted to int, but if it can be made to work, just do it.
The javascript one is blargh just because + is overloaded, making
it easy to accidentally do the wrong thing (this just bit me in a
real world code thing like 20
minutes ago, coincidentally). But I still prefer it to the last
one..
Which cares about the types enough to throw an exception, but
makes you wait for runtime to tell you about it. Pain in the butt
that leads to fragile code that just
breaks a lot.
For example, one version of a library returns numbers typed as
strings so you do some string stuff on them... then the next
version returns them typed as numbers and
the old string concat pieces now randomly break next time you run
it.
Pain! If I need to know what the type is anyway, please just give
me a compiler to catch this stuff.
Alas, the latter model is what Ruby and Python do :(
