martinboehme wrote: > > This is a good idea, thank you! > > Thank you! Although it's not my idea 😅 The original idea comes from a > colleague: @martinboehme :-) > > > But, does it matter that the moved-from state equate to the > > default-constructed state? That is true of smart pointers but perhaps that > > is not true of all types of which `bugprone-use-after-move` would care to > > be suppressed. What are the risks and benefits of > > `[[default_constructed_after_move]]` as compared to `[[usable_after_move]]`? > > @martinboehme may want to chime-in here. But conveying that the object is > left in the default-constructed state (and not other) is important for the > typical scenario where it will be used: smart pointer-like types.
Yes, this is why I suggested to @juanvazquez to give the attribute the "default constructed" semantics and name. As he explains, the primary use case for this attribute (that he and I are interested in) is to apply it to smart pointer types, which generally are null when moved from. The check should therefore warn if trying to dereference a moved-from smart pointer, but not, for example, when calling `.get()` on it. It may be, though, that we're in an unhappy middle ground here, and that we should either a) make the attribute more specific to smart pointers (e.g. `[[null_after_move]]`) or b) more general (i.e. leave out the "default-constructed" part, which would then make it less useful for smart pointers, though, because we wouldn't be able to warn on dereferences). If we do go with something like b), then I'd suggest that `[[usable_after_move]]` is maybe too vague: As @juanvazquez points out, any moved-from object is arguably "usable", in that it is in a valid-but-unspecified state. Maybe `[[defined_state_after_move]]` conveys more clearly that the moved-from state is not just guaranteed to be valid but is precisely defined? I agree, in any case, that this discussion should be taken to an RFC, where more people are likely to see it. https://github.com/llvm/llvm-project/pull/178432 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
