Timothy Lochner

see https://www8.open-std.org/JTC1/SC22/WG21/docs/papers/2020/p1887r1.pdf …

(it proposes exposing attributes as classes, the thing that spawned this thread)

Better to separate attribute names from types. If you want multiple point2 attributes, are you supposed to keep coining new point2-like structs? I put in attribute names as special types for this reason: using L1 [[attribute]] = point2; using L2 [[attribute]] = point2; etc

I disagree, I want strong typing on my _consumption_ of attributes, e.g. being able to dispatch attribute handling via function overloads or template specialization. Adding another "attribute name" entity that doesn't participate in the type system is not what I want.

I think some of your points stand about duplication, but I see that as orthogonal. We've wanted "opaque typedefs" in C++ for years; instead of an attribute-specific solve, I'd rather we keep attributes simple and extend C++ elsewhere to since the whole group of related issues.

What are the other users of opaque typedefs? I'd remove the attribute names and use those instead if there was another use case.

I always come up with the same example: Database IDs using UserId = int; using BookId = int;

you don't want those two to be interoperable in any way, it always leads to hard to debug issues. But at the same time, both are just ints in the DB engine