{"action":"created","issue":{"url":"https://api.github.com/repos/dart-lang/dev_compiler/issues/108","labels_url":"https://api.github.com/repos/dart-lang/dev_compiler/issues/108/labels{/name}","comments_url":"https://api.github.com/repos/dart-lang/dev_compiler/issues/108/comments","events_url":"https://api.github.com/repos/dart-lang/dev_compiler/issues/108/events","html_url":"https://github.com/dart-lang/dev_compiler/issues/108","id":64623250,"number":108,"title":"Infer list (and map?) literals based on the data they contain","user":{"login":"vsmenon","id":2119553,"avatar_url":"https://avatars.githubusercontent.com/u/2119553?v=3","gravatar_id":"","url":"https://api.github.com/users/vsmenon","html_url":"https://github.com/vsmenon","followers_url":"https://api.github.com/users/vsmenon/followers","following_url":"https://api.github.com/users/vsmenon/following{/other_user}","gists_url":"https://api.github.com/users/vsmenon/gists{/gist_id}","starred_url":"https://api.github.com/users/vsmenon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vsmenon/subscriptions","organizations_url":"https://api.github.com/users/vsmenon/orgs","repos_url":"https://api.github.com/users/vsmenon/repos","events_url":"https://api.github.com/users/vsmenon/events{/privacy}","received_events_url":"https://api.github.com/users/vsmenon/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":44,"created_at":"2015-03-26T20:18:57Z","updated_at":"2015-04-05T14:49:09Z","closed_at":null,"body":"This came up in recent discussions (@nex3 @kevmoo @leafpetersen).\r\n\r\nWe currently infer l in:\r\n\r\n```dart\r\nvar l = [\"hello\", \"world\"];\r\n```\r\n\r\nas `List<dynamic>`.  This causes issues if we use l in a context that requires `List<String>`.  As an alternative, we could infer l as a List with the narrowest static type that accommodates its contents.  In this case,\r\n\r\n```dart\r\nvar l = [\"hello\", \"world\"];\r\nl.add(42);\r\n```\r\n\r\nwould be an error.  Thoughts?"},"comment":{"url":"https://api.github.com/repos/dart-lang/dev_compiler/issues/comments/89787190","html_url":"https://github.com/dart-lang/dev_compiler/issues/108#issuecomment-89787190","issue_url":"https://api.github.com/repos/dart-lang/dev_compiler/issues/108","id":89787190,"user":{"login":"eernstg","id":9606994,"avatar_url":"https://avatars.githubusercontent.com/u/9606994?v=3","gravatar_id":"","url":"https://api.github.com/users/eernstg","html_url":"https://github.com/eernstg","followers_url":"https://api.github.com/users/eernstg/followers","following_url":"https://api.github.com/users/eernstg/following{/other_user}","gists_url":"https://api.github.com/users/eernstg/gists{/gist_id}","starred_url":"https://api.github.com/users/eernstg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eernstg/subscriptions","organizations_url":"https://api.github.com/users/eernstg/orgs","repos_url":"https://api.github.com/users/eernstg/repos","events_url":"https://api.github.com/users/eernstg/events{/privacy}","received_events_url":"https://api.github.com/users/eernstg/received_events","type":"User","site_admin":false},"created_at":"2015-04-05T14:49:09Z","updated_at":"2015-04-05T14:49:09Z","body":"On Tue, Mar 31, 2015 at 6:01 PM, vsmenon <notifications@github.com> wrote:\n\n> On Tue, Mar 31, 2015 at 8:52 AM, Erik Ernst <notifications@github.com>\n> wrote:\n> > On Tue, Mar 31, 2015 at 4:27 PM, vsmenon <notifications@github.com>\n> wrote:\n> > > On Tue, Mar 31, 2015 at 4:58 AM, Erik Ernst <notifications@github.com\n> > wrote:\n> > > > On Fri, Mar 27, 2015 at 6:34 PM, Leaf Petersen <\n> notifications@github.com> wrote:\n> > > > [..]\n> >\n> > [..do you..] restrict assignability to subtyping?\n>\n> We're still experimenting on this. When we don't restrict assignability,\n> we insert a runtime check when necessary (effectively the checked mode\n> check).\n\n\nI think it would be nice to be able to say \"the behavior of your compiled\nprogram is exactly checked mode\" or possibly \".. is checked mode plus extra\nchecks enforcing <some-specific-list-of-cases>\".  But if you change static\nassignability checks to subtype checks, couldn't you use that to insert\n_fewer_ checks than those inserted by a standard checked mode compilation\n(because they are statically guaranteed to succeed)?\n\n> Here's a case where we use different terminology: To me, Dart-checked-mode\n> > and Dart-production-mode are different languages, because they give rise\n> to\n> > different runtime semantics, even though the syntax is suspiciously\n> > similar. ;)\n>\n> I don't think our users see it this way. They develop in one and deploy in\n> (something like) the latter.\n\n\nOK, my choice of words was a bit polemic.  But still, I think it's\ndangerous to have different semantics and think of them as \"the same\nlanguage\".  If we have the situation where one execution terminates with a\nchecked-mode violation, and the other one runs in production mode and\nsurvives for a while after that, we might very well have, say, stored some\ninconsistent objects on disk or otherwise created problems for the future\nbecause of the undetected violation.  Code that ought to deal with that\ntype of situation would not exist, or it could be totally untested, because\nthe program was developed in checked mode and deployed in production mode.\nDo we get enough extra performance in production mode to make that a good\ntrade-off?\n\n  best regards,\n\n-- \nErik Ernst  -  Google Danmark ApS\nSkt Petri Passage 5, 2 sal, 1165 København K, Denmark\nCVR no. 28866984\n"}}