Why the result of 1 + "1" is "11"

[江添亮]

Why the result of evaluation: 1 + "1 ", is "11"?
I can understand "1" + 1 is evaluated to "11".
The document of String said so.
but why 1 + "1" is "11"?
spec said, e1 op e2 is evaluated as e1.op(e2).
So 1 + "1" invokes a method operator + from the type of 1,
(which is I guess some implementation defined class that isn't exposed
to the users.)
Interface num took a parameter as static type num and returns num.
with no document of how it works.
But I assume if it use static type num in an official document, it
doesn't expect a type that isn't a sub type of num.

[Florian Loitsch]

This is a limitation of DartC (the compiler that is used for the Dartboard): in order to get decent performance DartC is allowed to optimize under the assumption that checked mode doesn't throw any AssertionError. In particular this means that the type-check for num.+ does not throw.

In your example this assumption is violated and the result is thus undefined.

There is already a similar bug open: http://code.google.com/p/dart/issues/detail?id=208

// florian

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[江添亮]

On Oct 24, 1:24 am, Florian Loitsch <floit...@google.com> wrote:

> On Sun, Oct 23, 2011 at 17:49, 江添亮 <boost...@gmail.com> wrote:
> > Why the result of evaluation: 1 + "1 ", is "11"?
> > I can understand "1" + 1 is evaluated to "11".
> > The document of String said so.
> > but why 1 + "1" is "11"?
> > spec said, e1 op e2 is evaluated as e1.op(e2).
> > So 1 + "1" invokes a method operator + from the type of 1,
> > (which is I guess some implementation defined class that isn't exposed
> > to the users.)
> > Interface num took a parameter as static type num and returns num.
> > with no document of how it works.
> > But I assume if it use static type num in an official document, it
> > doesn't expect a type that isn't a sub type of num.
>
> This is a limitation of DartC (the compiler that is used for the Dartboard):
> in order to get decent performance DartC is allowed to optimize under the
> assumption that checked mode doesn't throw any AssertionError. In particular
> this means that the type-check for num.+ does not throw.
> In your example this assumption is violated and the result is thus
> undefined.
> There is already a similar bug open:http://code.google.com/p/dart/issues/detail?id=208

So it's a limitation of the DartC.
Thank you.

[Pimm Hogeling]

Just to clarify: as Florian kind-of mentioned, your example would raise a warning checked mode. In plain English: your example does not work in checked mode.

You can verify this yourself: try.dartlang.org/s/BWgd

By not testing your code in checked mode, you are ignoring any warnings that might have been raised during such a test.

2011/10/23 江添亮 <boos...@gmail.com>