{"comment":{"url":"https://api.github.com/repos/CaseyCarter/stl2/comments/11800948","html_url":"https://github.com/CaseyCarter/stl2/commit/2d54e6b6275c9d1f97b3c5d899171ef53ef5dc04#commitcomment-11800948","id":11800948,"user":{"login":"ericniebler","id":225757,"avatar_url":"https://avatars.githubusercontent.com/u/225757?v=3","gravatar_id":"","url":"https://api.github.com/users/ericniebler","html_url":"https://github.com/ericniebler","followers_url":"https://api.github.com/users/ericniebler/followers","following_url":"https://api.github.com/users/ericniebler/following{/other_user}","gists_url":"https://api.github.com/users/ericniebler/gists{/gist_id}","starred_url":"https://api.github.com/users/ericniebler/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ericniebler/subscriptions","organizations_url":"https://api.github.com/users/ericniebler/orgs","repos_url":"https://api.github.com/users/ericniebler/repos","events_url":"https://api.github.com/users/ericniebler/events{/privacy}","received_events_url":"https://api.github.com/users/ericniebler/received_events","type":"User","site_admin":false},"position":398,"line":743,"path":"concepts.tex","commit_id":"2d54e6b6275c9d1f97b3c5d899171ef53ef5dc04","created_at":"2015-06-22T18:53:48Z","updated_at":"2015-06-22T18:53:48Z","body":"@sean-parent wrote:\r\n> I agree with Andrew on this.\r\n\r\nYou mean, you agree with me (Eric) on this.\r\n\r\n> For references/proxy objects to the extent you want to try and support\r\n> them, copy independence becomes a pre-condition that references don't alias\r\n> the same object, not a type requirement.\r\n\r\nInteresting, thanks for this.\r\n\r\n@CaseyCarter wrote:\r\n>> The absence of copy independence is not the same as saying object\r\n>> access is not race-free.\r\n> \r\n> I don't mean undefined behavior due to a possible data race, I mean\r\n> undefined behavior from modifying the value of an object declared\r\n> const per [dcl.type.cv]/4.\r\n\r\nThis is wrong for a few reasons. (For context, the question was whether mutating one variable was invoking undefined behavior by mutating another variable, visible in the current scope via a `const &`.)\r\n\r\n1. Just because an object is visible in the current scope via `const &` doesn't mean the object was declared `const`. It is only UB to mutate an object declared `const`.\r\n2. Even for objects declared `const`, it is never undefined behavior to mutate a `mutable` member.\r\n3. It is my belief that the issue of whether a copy constructor satisfies its requirements (makes a copy, doesn't mutate the source object) even if it doesn't create independent copies has nothing to do with the behavior of operations applied *after* the constructor finishes, nor does it have anything to do with other operations happening concurrently on an alias.\r\n\r\nAgain, the interesting model to consider is a proxy. Proxies are absolutely `CopyConstructible`. Their copy constructor creates a copy (copies have equal values), and the constructor does not mutate the source object. If you want copy independence, use `Semiregular` or, as Sean observes, add a pre-condition that no objects alias each other."}}