martinboehme wrote: > > You mean the publicness of `getResultObjectLocation()`? > > Yeah, I was wondering if it would be more user friendly if something like > `State.Env.get<RecordStorageLocation>(Expr);` would automatically recognize > that the user actually wants the result location and returned that without > the user having to consider this special case explicitly.
Thanks, I understand now. I see the attraction, but I think it would dilute the semantics of `get<derived_from<StorageLocation>>`. Currently, this method may only be called on glvalues, and that makes it very clear what it will return -- as a glvalue _is a_ storage location. Extending `get<derived_from<StorageLocation>>` to do what `getResultObjectLocation()` does today means that it would become permissible to call this method on prvalues (of record type), and the semantics of what this operation does would be quite different from what it does on glvalues, and more involved -- because it would now be returning the storage location of a _different_ AST node (the result object), and connecting the AST node for the result object to the prvalue is not entirely trivial. I think it would therefore be better to make this difference in semantics clear by separating out the "get the result object location for a record prvalue" operation into a separate method. https://github.com/llvm/llvm-project/pull/78427 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
