> Gabriel Dos Reis writes: > If by analysis, you can determine ... The problem with this type of logic is that it leads to arbitrary inconsistent designation of an object's reference as a function of the breadth of the "analysis", therefore seems clearly undesirable.
Resulting in only two possibilities: A: Treat all object references as initially declared (which isn't technically possible as function parameter declarations make this impossible to begin with, and inherently inconsistent with lvalue cast semantics). B: Treat all object references as declared within their current scope, where the effective object declarations hierarchy looks basically like: <allocation-decl> [<parameter-decl> | <cast-decl>], where the most current represents the effective declaration of the object. Thereby (B) represents the only tenable choice (there is no in-between). [Which seems to be real simple to understand and abide by, regardless of whether or not the resulting reference may specify an undefined behavior; as the job of the compiler is to abide by the specified program, not go out of it's way attempting to identify undefined behaviors so that it may interject it's equally undefined inconsistent behaviors without regard to the factual behavior that it's target would otherwise yield naturally if it just simply warned and left well enough alone, presuming the author desired what was specified, not something otherwise.]