{"action":"created","issue":{"url":"https://api.github.com/repos/daokoder/dao/issues/400","labels_url":"https://api.github.com/repos/daokoder/dao/issues/400/labels{/name}","comments_url":"https://api.github.com/repos/daokoder/dao/issues/400/comments","events_url":"https://api.github.com/repos/daokoder/dao/issues/400/events","html_url":"https://github.com/daokoder/dao/issues/400","id":85542745,"number":400,"title":"Uninitialized variables: evil returns","user":{"login":"Night-walker","id":5074460,"avatar_url":"https://avatars.githubusercontent.com/u/5074460?v=3","gravatar_id":"","url":"https://api.github.com/users/Night-walker","html_url":"https://github.com/Night-walker","followers_url":"https://api.github.com/users/Night-walker/followers","following_url":"https://api.github.com/users/Night-walker/following{/other_user}","gists_url":"https://api.github.com/users/Night-walker/gists{/gist_id}","starred_url":"https://api.github.com/users/Night-walker/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Night-walker/subscriptions","organizations_url":"https://api.github.com/users/Night-walker/orgs","repos_url":"https://api.github.com/users/Night-walker/repos","events_url":"https://api.github.com/users/Night-walker/events{/privacy}","received_events_url":"https://api.github.com/users/Night-walker/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-05T14:10:06Z","updated_at":"2015-06-12T14:57:02Z","closed_at":null,"body":"Look at this, doesn't it feel fundamentally wrong?\r\n```ruby\r\n(dao) class A {\r\n..... var f: io::Stream\r\n..... }\r\n= none\r\n(dao) a = A()\r\n= A[024CECF8]\r\n(dao) a.f\r\n= none\r\n(dao) x: A\r\n= none\r\n(dao) x\r\n= none\r\n(dao) io.writeln(x)\r\n# CRASH\r\n```\r\nUnitialized variables are `none` whereas their type has no indication of it. This throws us back to the ~~Medieval age~~ same problem with magic 'no-value' which can slip in everywhere and ruin seemingly correct code. And it's not even the \"good none\", it's some kind of bad, evil `none` which evidently may lead to crashes.\r\n\r\nThat's a serious flaw, and it should be fixed. And the only plain and simple solution I see is forbidding the use of uninitialized data once and for all. Everywhere. So that it can never break free and cause havoc during code execution.\r\n\r\nFirst, all standalone variables must be initialized at the place of their definition *unless* we can track their further use and ascertain that it is 100% correct in all possible cases, always. Apparently, it doesn't work that way at present.\r\n\r\nSecond, constructors must initialize all class fields. If that is somehow problematic to ensure (and it seems for me that it may be so), then the very idea of constructor must change. I, for one, can propose Rust's approach: no constructors; create objects manually (via static methods) specifying all their content immediately without missing a single field. As with `Class.{...}` packing in Dao.\r\n\r\nThat's it."},"comment":{"url":"https://api.github.com/repos/daokoder/dao/issues/comments/111518418","html_url":"https://github.com/daokoder/dao/issues/400#issuecomment-111518418","issue_url":"https://api.github.com/repos/daokoder/dao/issues/400","id":111518418,"user":{"login":"daokoder","id":1860002,"avatar_url":"https://avatars.githubusercontent.com/u/1860002?v=3","gravatar_id":"","url":"https://api.github.com/users/daokoder","html_url":"https://github.com/daokoder","followers_url":"https://api.github.com/users/daokoder/followers","following_url":"https://api.github.com/users/daokoder/following{/other_user}","gists_url":"https://api.github.com/users/daokoder/gists{/gist_id}","starred_url":"https://api.github.com/users/daokoder/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/daokoder/subscriptions","organizations_url":"https://api.github.com/users/daokoder/orgs","repos_url":"https://api.github.com/users/daokoder/repos","events_url":"https://api.github.com/users/daokoder/events{/privacy}","received_events_url":"https://api.github.com/users/daokoder/received_events","type":"User","site_admin":false},"created_at":"2015-06-12T14:57:02Z","updated_at":"2015-06-12T14:57:02Z","body":"> Now, after the latest commit, it's impossible to declare reference-based values without initialization.\r\n\r\nRight. I hope this does not create much inconvenience.\r\n\r\n>  I'd suggest to extend this rule on all variable types. Relying on default values makes the code confusing and error-prone; besides, initializing a variable with e.g. 0 or \"\" should bear no overhead anyway.\r\n\r\nAgree. It will be done.\r\n\r\n> Yes, the check for uninitialized variables works -- but it works at runtime. Not very nice, performance suffers too. It's OK as a temporary workaround, but I think we should adopt a better alternative in the long run.\r\n\r\nI think the checking can be done at compiling time in principle. It is very simple for object packing (uniform initialization). But for constructors, it will need some static program analysis, it is not difficult, if the members are required to be initialized right inside the constructors. But if the constructors call other method to do the initialization, it may become very tricky in some cases.\r\n\r\nIt seems to me that, requiring class members to be initialized inside constructor bodies is completely acceptable, because one can always build values with methods, and return and **assign** them to the members inside constructors. In this case, I will consider to add static checking at compiling for class members."}}