{"id":21943420,"url":"https://github.com/janwilmans/futurecpp","last_synced_at":"2025-08-25T00:41:12.319Z","repository":{"id":75898212,"uuid":"140199275","full_name":"janwilmans/futurecpp","owner":"janwilmans","description":"The future of C++ ; What must change and why?","archived":false,"fork":false,"pushed_at":"2018-07-15T14:40:05.000Z","size":12,"stargazers_count":0,"open_issues_count":3,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-02-03T16:51:44.160Z","etag":null,"topics":["cpp","cpp20","futurecpp","standarization"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/janwilmans.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-07-08T20:11:51.000Z","updated_at":"2018-07-15T14:40:06.000Z","dependencies_parsed_at":null,"dependency_job_id":"0da8c097-7b3f-466c-842b-1cc0928a235a","html_url":"https://github.com/janwilmans/futurecpp","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/janwilmans%2Ffuturecpp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/janwilmans%2Ffuturecpp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/janwilmans%2Ffuturecpp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/janwilmans%2Ffuturecpp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/janwilmans","download_url":"https://codeload.github.com/janwilmans/futurecpp/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":244981284,"owners_count":20542288,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cpp","cpp20","futurecpp","standarization"],"created_at":"2024-11-29T03:30:03.874Z","updated_at":"2025-03-22T15:44:08.190Z","avatar_url":"https://github.com/janwilmans.png","language":null,"readme":"# The future of C++ ; What must change and why?\n\nC++ is a very versitile language, its now in its twenties and carrying legacy features all the way back to 1979.\nThis repository aims to collect rationales for features that we should:\n\n* nolonger use, unless to compile legacy code\n* depricate / completely remove support from the language\n* change / add to the language\n* NOT add to the language\n\nDiscussions questions that come to mind are:\n* should we leave legacy code bases behind at some point? \n* if not, how can we expect compiler vendors to sustain them indefinately?\n* can or should we make the language safe(r) by default and more relaxed when performance requires it?\n* ... in you think of more, let me know, I will add them\n\nI will search for past discussion, summarize and link here.\nAnd also start discussions on Twitter and collect the results here.\n\nmore coming...?\n\n# should we leave legacy code bases behind at some point?\n\nI would like to write down some solid arguments here (pro or con), other then 'we cant'\n\n# how can we make the language safe(r) by default and more relaxed when performance requires it?\n\nWhat do I mean with 'safe(r)' and why should this be a goal?\nI think one of the reasons that 'c++ is hard' is a pervasive statement, is that the default behaviour in many cases is based on what costs the least in terms of run-time overhead. The **you don't pay for what you don't use** logic is applied here. However, for programmers that do not read the standard in the entirety, knowing what you **are** actually using can be hard and what you 'get' is sometimes undefined (or at least expected) behaviour.\n\nWhat if we could make the language safe(r)-by-default? By safer I do not garbage collection or other resource management, I mean range checking is a good default, any no problem to turn off when you design provides other means to guarantee invalid acceses do not happen.\n\nSome of my own pet peeves are:\n\n1) a feature toggle to disable the use of **new** and **delete** \n2) a feature toggle to always initialize **all** variables and emit a warning when its not explicitly done.\n3) a feature toggle to disable implicit conversion between unrelated types (bool \u003c\u003e integer \u003c\u003e double \u003c\u003e class)\n4) a feature toggle for switching for the keyword typedef\n\nwhat about adding support in the standard to sub-set on certain features.\nOfcourse, you could argue why this would need to be in the standard at all. I think the main reason is, \nso all major vendors will implement this in the same way. It would be bad to fragment the c++ users/community into different dialects like what happens with exceptions and dynamic allocations.\n\nI am worried that 2) might promote bad practice, like not initilizing variables ever, because the 'compiler will do it'.\nHowever, if it would emit a warning, that might at least discourage  new coders from doing this.\n\n\n# many we need more/other warnings? (aka diagnostics as compiler builder call them)\n\n```\nclass Foo \n{\npublic:\n  Foo(int\u0026 x) : a(a) {}     // mistake: a = a, iso a = x;\n\n  int \u0026a;\n  \n  Foo(Foo\u0026\u0026 rhs) noexcept  // mistake: a = a, iso a = rhs.a;\n    : a(a)\n    {\n    }    \n};\n```\n\nBoth cases fo unnoticed by VS2017 and GCC, but clang reports: reference 'a' is not yet bound to a value when used here [-Wuninitialized])\n\n\n\n\n\n\n\n\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjanwilmans%2Ffuturecpp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjanwilmans%2Ffuturecpp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjanwilmans%2Ffuturecpp/lists"}