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"

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 :(

Reply via email to